So arbeite ich im Projekt
Ich arbeite als Teammitglied auf Zeit: Ich schreibe Code, gestalte Storys mit und trage das Ergebnis des Teams mit. Schwächen spreche ich offen an, in der Runde, in die sie gehören. Und ich sorge von Anfang an dafür, dass das Wissen im Team bleibt, wenn ich wieder gehe.
Ich arbeite im Team mit, nicht von außen
Je nach Projekt bin ich Entwickler, Architekt oder DevOps Engineer im Team. Ich nehme an denselben Terminen teil wie alle anderen. Die Leistung des Teams steht vor meiner eigenen, und mir ist wichtig, dass das ganze Team ein gutes Bild abgibt.
Von festangestellten Kollegen unterscheidet mich vor allem die Erfahrung aus vielen Unternehmen. Fallen mir Schwächen in Strukturen oder Prozessen auf, schlage ich Verbesserungen vor und lege meine Argumente dar. Ich arbeite überwiegend remote und komme nach Absprache vor Ort.
In den ersten zwei Wochen sammle ich, bevor ich etwas ändere
Ich stelle eine Liste aller Ansprechpartner mit ihren Rollen zusammen. Ich frage nach Codestand, Dokumentation, nicht-funktionalen Anforderungen und Coding Guidelines. Und ich lasse mir erklären, wie die Teams arbeiten und welche Termine es gibt.
Dann verschaffe ich mir einen Überblick über Architektur und zentrale Werkzeuge, etwa Kubernetes, SonarQube oder den Scanner für Sicherheitslücken. Ich besorge mir die Zugänge, lege Linklisten an und richte meine Arbeitsumgebung ein.
Angekommen bin ich, wenn ich die Zusammenhänge verstehe und meine Änderungen auf Anhieb passen. Ab dann warte ich nicht mehr auf Aufgaben, sondern gestalte die Ergebnisse des Teams mit.
Unbequemes spreche ich in der Runde an, in die es gehört
Fehler und Schwächen, die ich sehe, bringe ich ins Daily, ins Refinement, ins Planning oder in die Retro. Ich setze mich für klare Absprachen ein. Vor dem Start steht eine Definition of Ready, und die Definition of Done hält auch Qualität und Wartbarkeit fest.
Bei technischen Schulden sage ich deutlich meine Meinung und begründe sie. Die Entscheidung bleibt beim Team. Wählt es den schnellen Weg, bestehe ich darauf, dass die Schuld als Ticket festgehalten wird. In die Definition of Done gehört für mich ein Punkt wie „keine neuen technischen Schulden“.
Ich achte darauf, dass Teams miteinander reden
Viele technische Probleme haben eine organisatorische Ursache. Wo Teams nicht miteinander reden, passt auch die Software nicht sauber zusammen.
Ich habe zwei Setups mit mehreren Teams erlebt, darunter ein Scrum of Scrums mit vier Teams. Eines hat funktioniert, das andere nicht. In beiden gab es übergreifende Meetings, in denen die Teams ihre Bedarfe aneinander verstanden haben.
Den Unterschied machten zwei Dinge: ein regelmäßiger Austausch über Probleme bei der Umsetzung und über den kritischen Pfad. Und die Nachverfolgung von delegierten Aufgaben und Zulieferungen.
Wo das klappte, hatten alle Teams dasselbe Bild vom nächsten Inkrement. Probleme zwischen Teams wurden früh gelöst, nicht erst hektisch beim Deployment am Ende des Sprints.
Den Nutzen zeigt der Betrieb, nicht meine Überzeugungskraft
In einem Großprojekt im Bereich Mobilität habe ich eine Überwachung fachlicher Kennzahlen für den First-Level-Support aufgebaut. Wir waren ein Team von etwa zehn Personen, abgestimmt habe ich mich mit dem Teamleiter. Der Support sagte zunächst, er brauche das nicht. An einigen Tagen saß ich selbst im Telefonsupport.
Ein Jahr später erkannten die Kollegen im Support Fehler, bevor der erste Anruf kam, und konnten am Telefon klare Auskünfte geben. Fiel das System einmal aus, haben sie es sofort vermisst. Überzeugen musste ich niemanden.
Dem Product Owner erkläre ich anders als dem Management
Ich erkläre in einfacher Sprache, was sich ändert, welchen Vorteil es bringt und worin sich die Wege unterscheiden. Mit dem Product Owner spreche ich so technisch, wie es sein Hintergrund erlaubt. Ich habe mit Product Ownern gearbeitet, die selbst programmiert haben, und mit solchen aus dem Fachbereich.
Wo es hilft, begründe ich mit Abläufen, Sicherheitslücken oder Bedienbarkeit. Und wenn ein Bild mehr sagt als ein Absatz, skizziere ich ein einfaches Schaubild.
Das Wissen bleibt im Team, wenn ich gehe
Dafür sorge ich während der ganzen Zeit, nicht erst bei der Übergabe. Pairing ist bei mir Standard, auch weil zwei Leute schneller besseren Code schreiben. Mindestens eine Person versteht, woran ich arbeite, besser zwei aus unterschiedlichen Bereichen. Das entlastet auch mich, zum Beispiel im Urlaub.
Dokumentation lege ich ohnehin für mich selbst an. Sie ist praxisnah und auf Ausführung und grobe Zusammenhänge beschränkt. So bleibt sie wartungsarm und stimmt lange.
Ob das Team eine Technologie weiterverwendet, die ich eingeführt habe, entscheidet das Team.
Gut läuft es mit Zugängen ab dem ersten Tag und klaren Entscheidungswegen
Sie bekommen Risiken früh auf den Tisch und Argumente statt Meinungen. Damit das gelingt, hilft mir:
- Zugänge ab dem ersten Tag und ein fester Ansprechpartner
- klare Ziele, Prioritäten und Entscheidungswege
- Einbindung ins Team wie alle anderen, ohne Sonderrolle am Rand
- Offenheit für Kritik und Vorschläge
- eine Planung, in der Tests, Dokumentation und Wissensweitergabe Platz haben
Bei der Planung rede ich gern mit, statt eine Zeit vorgegeben zu bekommen. Wenn wir Umfang und Zeit gemeinsam besprechen, wird für beide Seiten sichtbar, was eine Entscheidung oder ein enger Zeitplan bedeutet.
Wenn Sie ein kleines Unternehmen sind
Dieselben Grundsätze gelten auch, wenn Sie keine eigene IT-Abteilung haben. Für Ihre Firma arbeite ich über die Itinno GmbH.
Wie läuft die Zusammenarbeit mit mir ab?
In einem schlanken Scrum: Ihre Ziele und Anforderungen, auch die nicht-funktionalen, halte ich als kurze User Storys fest. Einmal pro Woche zeige ich, was fertig ist, wir klären die nächsten Anforderungen und planen die kommende Woche. Ich übernehme dabei die Aufgaben von Lead Developer und Product Owner und bespreche mit Ihnen, was in welches Paket gehört.
Wie erfahren Sie, wo das Projekt steht?
Im wöchentlichen Termin sehen Sie den Zwischenstand und können direkt Rückmeldung geben.
Was passiert, wenn ich ausfalle?
Ich sage es so früh wie möglich und stimme mit Ihnen einen neuen Termin ab. Weil ich laufend dokumentiere, hängt das Wissen über Ihr Projekt nicht allein an mir.
Was bekommen Sie am Ende in die Hand?
Eine laufende Lösung und den Quellcode. Was genau zur Übergabe gehört, regelt der Vertrag mit der Itinno GmbH.
Worauf Sie sich bei mir einstellen können
- Ich stelle Rückfragen und mache Vorschläge, statt nur nach Vorgabe zu programmieren.
- Ich weise auf technische Schulden und Sicherheitslücken hin, auch wenn es unbequem ist.
- Umfang und Termin plane ich gemeinsam mit Ihnen.
- Eine schnelle Lösung für den Anfang baue ich gern. Wir halten dann fest, was später nachgezogen wird.
- Ich brauche einen festen Termin pro Woche für die Abstimmung.
- Passt eine fertige Standardsoftware besser zu Ihnen, sage ich Ihnen das.
Über mich
Mich treibt die Brücke zwischen Systemen und den Menschen an, die damit arbeiten. Am deutlichsten habe ich das im Support eines Großprojekts erlebt: Zuerst wollte dort niemand die neue Überwachung, ein Jahr später haben sie alle vermisst, als sie einmal ausfiel.
Dass ich Consultant werde, war am Anfang nicht abzusehen. Als ich nach einem Berufseinstieg gesucht habe, kannte ich nur zwei Berufe: Java-Programmierer und Systemadministrator. Was ein Consultant ist, habe ich erst in einer BWL-Vorlesung an der Uni erfahren. Das Berufsbild hat mich nicht mehr losgelassen. Ich habe mich gezielt als Consultant beworben und bin drangeblieben, bis es geklappt hat. In meiner ersten Stelle hat mich ein Senior-Entwickler zwei Monate lang in Java EE gefördert, bevor ich in mein erstes Projekt kam. Seitdem bin ich Consultant, seit 2018 selbstständig und heute mit meiner eigenen Firma, der Itinno GmbH.
Während der Projekte habe ich mich viele Stunden weitergebildet: mit Büchern, im Netz, auf Seminaren und Messen. Dabei ist mir klar geworden, wie groß die Lücke zwischen Ausbildung, Studium und der Berufswelt ist. Daraus ist die Idee für meine Kurse für Einsteiger entstanden. Ich möchte Einsteiger so fördern, wie ich selbst am Anfang gefördert wurde: praktisch, ohne theoretischen Ballast und mit direktem Bezug zu dem, was in Projekten heute gebraucht wird.
In einem Team fühle ich mich wohl, wenn die Atmosphäre stimmt und ich die Ergebnisse mitgestalten kann. Daran arbeite ich in jedem Projekt, von der Ansprechpartnerliste am ersten Tag bis zur Übergabe am letzten. Dabei lerne ich nie nur über Technik, sondern immer auch über die Menschen, die damit arbeiten.
Was ich zurückgebe
Mindestens 1 % meines Umsatzes geht an soziale Projekte. Ich unterstütze Organisationen, die Menschen mit Bildung und medizinischer Versorgung zu einem selbstbestimmten Leben verhelfen: Plan International, den Arbeiter-Samariter-Bund und Ärzte ohne Grenzen.
