Inner Circle Project-Leading

25 Seiten agiles Manifest

Softwareprojekte – vor allem Großprojekte im B2B-Umfeld – sind eine immense Herausforderung. Unter dem Schlachtruf der „Agilität“ werden die alten Leinen der Steuerung über Bord geworfen und mehr Verantwortung an die Teams übertragen. Dabei umfasst das „Agile Manifest“ als Leitfaden der agilen Arbeitsweise in Softwareprojekten nicht mehr als 25 Seiten. Es soll schließlich auch lediglich ein Leitfaden darstellen. Bedeutet aber auch: Für alle weiteren detaillierten Antworten sind Projektverantwortliche auf sich alleine gestellt.

25 Seiten, 20 Jahre alt

Das Manifest ist 20 Jahre alt! Es sind zwei signifikante Unterschiede zwischen der Erstveröffentlichung des Manifests und heute zu beobachten:

1. Software-Projekte können heutzutage erheblich größere Dimensionen mit 100 Entwickler:innen und mehr aufweisen. Wie sind diese ganzen Menschen synchronisierbar? Jeder sucht sich ein Ticket vom Sprint-Board kann offensichtlich nicht mehr funktionieren. Lösungsansätze versuchen sich in Schablonen für Team-Aufteilung (z.B. „Domain Driven Design“ oder das ganz große Schlachtschiff „SAFe“), oft ohne Bewusstsein für Folgeherausforderungen, zum Beispiel unvermeidbarer Informationsverlust und steigende Abstimmungsaufwänden.
2. Ein weiterer Unterschied zu „damals“: Heutzutage haben sich die Disziplinen eines Softwareprojekts erheblich differenziert, es braucht UX, CSS, JavaScript, Framework-Erfahrung zu Angular, React & Vue, aber natürlich auch zu API-Design, Datenbank-Technologien und DevOps. Die theoretischen Lösungen dieses Spagats scheinen einfach: Ganz vorne ist der Titel „Full-Stack-Entwickler:in“. Dieser Ein-Entwickler:in-God-Mode kann alles und damit ist das natürlich Problem gelöst. In Kombination mit Team-Aufteilungen kommt gerne die Variante von zentralen Kompetenz-Teams in Frage. Oft gesehene Folge: Konkurrenzdenke zwischen den Teams inkl. Schuldzuweisungen.

Das Kernproblem: Schwindende Verantwortungsübernahme in den Teams

Projektbeteiligte finden sich mehr und mehr in einem Getriebe an Teams, Rollen, Kompetenzen und Prozessen. Der Anteil der eigenen Arbeit am Gesamtprodukt schwindet und interne Reibungsverluste bremsen. Damit verschiebt sich unweigerlich die Kernmotivation weg vom erfolgreichen Produkt hin zum Erfolg der kleinen eigenen Nische.

Die Krux: „Agilität“ sieht als einen Grundpfeiler die Verantwortungsstärkung in den Teams. Frage: Sind die Projektbeteiligten unter den gegebenen Zwängen von Abhängigkeiten überhaupt in der Lage umfassend im Sinne des erfolgreichen Produkts zu agieren? Unsere These ist: Ja, aber nur in einer gut modellierten Lieferkette, in der jeder nur für seinen Bereich die Verantwortung tragen muss.

Was definitiv nicht funktioniert: Ein theoretisches Team-Setup aufstellen + Die Teams „agil“ machen lassen.

Der Folgeschluss: Es braucht auch ganz unagile Grenzen. Aber welche? Und wie lassen sie sich kommunizieren und motivieren?

Dazu eine schlechte und eine gute Nachricht:

Die schlechte Nachricht: Es gibt kein Patentrezept

Jedes Projekt ist anders, Teams, Fachlichkeit, Budgets, Zeitachsen…Die Lösung kann nur sein: So effizient wie möglich Ursachen zu sehen, Handlungsfähig in Bezug auf Prozesse zu bleiben und möglichst schnell zu lernen.

Die gute Nachricht: Die Veranstaltung, um die es bei diesem Post eigentlich geht

Wir wollen uns im vertrauten, nicht zu großen Kreis quartalsweise zu all den Herausforderungen austauschen, Erfahrungen teilen und Lösungsansätze diskutieren.

Rahmen-Agenda

• 15min Kurze Vorstellungsrunde bei neuen Teilnehmern
• 20min Impulsvortrag zu einem zuvor abgestimmten Thema
• 45min Offener Austausch zu Erfahrungen rund um das Thema
• 10min Beschluss des Folgethemas

Aktuelle Themenvorschläge

Die Themen werden im Vorlauf der Veranstaltungen gemeinsam beschlossen. Angedacht sind aktuell:

• Budget- und Terminsicherheit in agilen Zeiten: Ein Widerspruch?
• Entwickler != Kunde: Wie sind Aufwände im Sinne des Kunden steuerbar?
• Fachlichkeit: Das große Nadelöhr im Anforderungsmanagement managen
• Motivation und Stimmung in stressigen Projektzeiten: Ursachen und mögliche Maßnahmen

Nächster Termin

Noch nicht final terminiert (Ein Mittwoch Ende Januar) – 18h Online

Bei Interesse

Wenn Sie Interesse an einer Teilnahme haben, kommen Sie bitte direkt per E-Mail und mit Angabe Ihrer Projektkontexte und Interessen auf Daniel Greitens, CEO von MAXIMAGO zu: dgr@maximago.de.

Bitte haben Sie Verständnis, dass auf Grund der erwünschten offenen Kommunikation nicht jede Anfrage berücksichtigt werden kann. Daher wird jeder Interessent von der Gruppe der Teilnehmern akkreditiert.