– ein Gastbeitrag von Alicia Hickey, Softwareentwicklerin bei unserem Sponsor DCSO
Dank der Empfehlung eines befreundeten Agile Coachs war ich im letzten Jahr zum ersten Mal selbst beim PM Camp Berlin dabei. Die offene, herzliche Community einerseits sowie die spannenden Themen andererseits haben mich begeistert. Letztere erschienen mir vor allem für alle, die häufig mit Menschen zusammenarbeiten, sehr relevant… und das betrifft letztlich die meisten von uns.
Deshalb freut es mich besonders, dass wir von der DCSO in diesem Jahr zum ersten Mal Sponsor des PM Camp Berlin sind! Unsere Teams genießen prinzipiell viel Freiräume, wenn es darum geht, sich und ihre Arbeit zu organisieren. In diesem Beitrag möchte ich den Fokus konkret auf TI-Dev (das ist die Abkürzung für Threat Intelligence Development) richten – nicht zuletzt deshalb, weil es das Team ist, dem ich angehöre und bei dem ich zur Teamorganisation beitragen konnte.
Wir alle sitzen im selben Boot
Ich möchte meinen Zugang anhand des Beispiels der Segelboot-Analogie darstellen. Für diejenigen, denen dies kein Begriff ist, eine kurze Erklärung vorab: Das „Segelboot“ (im Englischen „Sailboat“, manchmal auch „Speedboat“) ist eine Technik für sogenannte Retrospektiven, in denen der Leiter dieser Besprechung (oder, wenn vorhanden: der Scrum Master) ein Segelboot stellvertretend für das Team zeichnet. Ein oder mehrere Anker repräsentieren jene Faktoren, die das Boot bremsen, eine Wolke symbolisiert den Wind in den Segeln des Teams, der das Boot vorwärtstreibt.
Anmerkung: Im Verlauf der Zeit habe ich meine Darstellung des Boots kontinuierlich verfeinert. Etwa, weil aus dem Team das Feedback kam, dass das Segel relativ zum Wind in die falsche Richtung zeigt oder weil Anker- und Bootsgröße nicht im richtigen Verhältnis standen. Bemerkenswert, was manchen Teams so ins Auge sticht!
Der Wind, der uns antreibt
Insbesondere die folgenden Faktoren sorgen bei uns für Vortrieb:
- Häufige, regelmäßige Check-Ins mit möglichst vielen Stakeholdern
Wir sind in der glücklichen Lage, dass wir den größten Teil unserer Arbeit für interne Stakeholder leisten. Häufig müssen wir nur an die Bürotür nebenan klopfen, um Feedback zu erhalten oder Details rund um ein Feature zu klären, an dem wir gerade arbeiten. Dennoch: Wir haben festgestellt, dass wir uns mit einem regelmäßigen Meeting (in unserem Fall um 11:30 Uhr am Montagvormittag) die Möglichkeit schaffen, als Team gemeinsam den Fortschritt beim Produkt, das wir bearbeiten, sowie offene Fragen oder Probleme damit zu diskutieren. Das Beste daran ist jedoch: Alle Developer sehen den Impact ihrer Arbeit – den positiven und den negativen. Wer Scrum kennt: Dieses Meeting ist dem Sprint Review recht ähnlich. - Einsatz der selben Technologie in mehreren Projekten
Wir nutzen das Django-Framework für zwei Apps, sodass wir Erkenntnisse und Wissen aus einem Projekt auch auf das andere übertragen können. - Für die Programmierer unter den Leserinnen und Lesern
Wir setzen auf trunk-basierte Entwicklung (trunk-based development). Was bedeutet das in der Praxis? Wir verpflichten uns dazu, mehrmals täglich „auf dem Master Branch einzuchecken“ und verschwenden keine Zeit damit, auf Merge Request Approvals zu warten.
Die Anker, die uns bremsen
Auch, wenn an einigen dieser Faktoren bereits gearbeitet wird, sind sie dennoch erwähnenswert:
- Häufiger Wechsel der Rahmenbedingungen
Als das TI-Dev-Team Anfang des Jahres gegründet wurde, wartete bereits ein großes Backlog an Themen, das unsere Aufmerksamkeit benötigte. Um allen Anforderungen und Beteiligten zu entsprechen, arbeiteten wir an jedem Thema zwei Wochen am Stück. Dabei handelte es sich nicht um kleine Einzelprojekte, sondern vielmehr um „Produkte“, die auf absehbare Zeit Entwicklungs- und Wartungsaufwand bedurften. Vor dem Hintergrund, Dynamik und Kontinuität zu gewährleisten, haben wir schließlich den einen Zweiwochen-Sprint in zwei jeweils einwöchige Sprints transformiert. Das brachte bereits erste, zarte Erfolge. Mittlerweile sind wir in Richtung längerer Perioden unterwegs. Aus Erfahrung kann ich sagen: Sechs Wochen fühlen sich heute wie eine Ewigkeit an, verglichen mit davor! - Kein eindeutiger Product Owner
Derzeit fehlt es uns noch an einer klar definierten Person in unserem Team, die eindeutig für Produktentscheidungen verantwortlich ist. Unsere derzeitige Lösung verteilt die Verantwortlichkeiten im gesamten Team. Das funktioniert so halbwegs und bringt den Vorteil mit sich, dass die Teammitglieder ein paar zusätzliche Product Skills erwerben können, z.B. im Rahmen von User-Tests oder Backlog Refinement Sessions. Dennoch liegt letztendlich ein Großteil der Last auf den Schultern der Teamleiter, sodass die Prioritäten des Teams und jene des Produkts miteinander konkurrieren.
Wenn du, der bzw. die das gerade liest, also ein „Produktmensch“ bist, melde dich gerne bei uns oder schicke uns deine Bewerbung!
Ich freue mich auf das PM Camp 2019, bin gespannt, was mich diesmal erwartet und möchte möglichst vielen Kolleginnen und Kollegen diese tolle Veranstaltung zeigen!
Zu Alicia Hickey
Alicia arbeitet als Software-Entwicklerin für die DCSO. Die DCSO wurde 2015 von Allianz SE, BASF SE, Bayer AG und Volkswagen AG als europäisches Kompetenzzentrum für Cyber-Sicherheit in der Wirtschaft gegründet. Cyber-Sicherheit für Europas Wirtschaft – das ist unser Auftrag. Wir vereinen deutsche Unternehmen, Forschungsinstitute, Behörden und unsere DCSO-Experten in Deutschlands führender Cyber-Sicherheits-Community. Gemeinsam arbeiten wir für Cyber-Sicherheit und effektive, effiziente Verteidigungsstrategien für die Unternehmen Europas.
