Scrum und Kanban als Betriebssysteme für Planungsabteilungen

Heute unterstütze ich als Management Consultant Teams und Organisationen bei der Einführung agiler Arbeitsmethoden und bei der agilen Gesamttransformation. Dabei bin ich in ganz unterschiedlichen Branchen unterwegs. Die Baubranche kenne ich aufgrund meines beruflichen Werdegangs von innen, blicke aber mittlerweile auch von außen – aus der Perspektive anderer Branchen – auf diesen Bereich.Dabei komme ich zu einer klaren Einsicht: Ich wäre froh gewesen, wenn ich vor zehn Jahren die agilen Frameworks Scrum und Kanban schon gekannt hätte, mit denen ich mittlerweile täglich arbeite. Dabei geht es nicht darum, dass ich beispielsweise Scrum 1:1 umgesetzt hätte. Nein, das agile Mindset, die Selbstorganisation eines Teams mit Klebezetteln, die Scrum- und Kanban-Prinzipien, all das hätte mir geholfen, mein Team besser zu organisieren und produktiver zusammenzuarbeiten.Aber wie hätten die damaligen Projekte nach heutigen Maßstäben aussehen können? Im Folgenden möchte ich euch einige hypothetische Szenarien vorstellen, um zu veranschaulichen, welches Potenzial agiles Denken auch in der Baubranche entfalten kann.

Ausgangssituation 1: Gründung und Führung eines Planungsteams

Worum ging es damals? Ich war in einem Generalbauunternehmen tätig. Wir hatten gewisse Probleme mit der Gebäudetechnikplanung und waren auf externe Fachplaner angewiesen, die ihren Job mehr schlecht als recht machten. Also beschlossen wir, die Technische Gebäudeausrüstung (TGA) künftig in Teilen selbst zu planen. Da auch wir aufgrund des Fachkräftemangels keine TGA-Fachingenieure aus dem Hut zaubern konnten, bestand unser Team aus jungen lernwilligen, doch fachfremden Ingenieuren sowie ein paar alten Hasen, die als Freelancer ihre Erfahrung einbrachten.

Die Aufgaben und Herausforderungen für das Planungsteam

• Aufgabenverteilung im Team
• Transparenz gegenüber Vorgesetztem und Sponsor über Tätigkeiten und Auslastung der Teammitglieder
• Erzielung greifbarer Ergebnisse und Darstellung der Produktivität
• Bearbeitung einer Mischung aus konkreten kleineren Planungsaufgaben in den Projekten und der Erarbeitung ungewöhnlicher Konzepte wie z. B. dem Direkteinkauf von Komponenten bei Herstellern oder der Werkstatt-Vorfertigung von Rohrleitungsmodulen
• Aufbau einer Planungsdatenbank mit dem Ziel, eine modulare TGA-Planung per Klick generieren zu können
• Wissenstransfer mit dem Ziel, das Wissen der erfahrenen Kollegen für künftige Projekte nutzbar zu machen
• Qualitätssicherung der externen TGA-Fachplanungen aber auch unserer eigenen Planungsbeiträge durch die erfahrenen Ingenieure

Was hätte ich im Rückblick anders gemacht, jetzt da ich agiles Arbeiten kenne?

Wir hätten uns intensiver darum gekümmert, im Team und mit dem Vorgesetzten ein gemeinsames Verständnis davon zu entwickeln, was wir erreichen wollen. Wir hätten uns sogar auf Fertigungskriterien geeinigt, wie wir Step by Step zum gemeinsamen Ziel gelangen wollen (zum Beispiel mit User Storys und einem Backlog). Wir hätten uns zudem regelmäßig und funktionsübergreifend die nächsten Schritte angesehen (z. B. mit Hilfe eines Refinement bzw. Estimation Meetings).Statt uns im Team auf unsere jeweilige Spezialisierung zu konzentrieren, wäre es hilfreich gewesen, wenn wir ganz bewusst zu zweit an Aufgaben gearbeitet hätten, um gegenseitig mehr voneinander zu lernen. Dadurch hätten wir zum einen das Denken in TGA-typischen Silos, wie z. B. Ingenieur vs. Technischer Zeichner, begrenzt und wären flexibler in der Aufgabenbearbeitung geworden. Zum anderen wäre es leichter gewesen, für eine gleichmäßige Auslastung der Teammitglieder zu sorgen. Auf jeden Fall hätten wir Spaß daran gehabt, cross-funktional an und mit unseren „T-shaped Skills“ zu arbeiten.Um unsere Aufgaben zu organisieren, nutzten wir ein Online-Kollaborationstool. Das funktionierte zwar technisch wunderbar, jedoch hatten wir Schwierigkeiten damit, die richtige Granularität der Aufgaben zu finden. Hier hätten uns übergeordnete User Storys (d. h. aus Nutzersicht formulierte Funktionalitäten) geholfen, uns nicht zu sehr im Klein-Klein des Aufgabenmanagements zu verlieren, sondern uns auf das große Ziel zu fokussieren.Ein tägliches Stand-up-Meeting vor einem physischen Taskboard hätte unsere Kommunikation und Selbstorganisation zudem verbessert.

Ausgangssituation 2: Gründung und Führung der Planungsabteilung

Springen wir nun in eine andere berufliche Situation, ein paar Jahre nach der eben beschriebenen Erfahrung mit meinem ersten TGA-Planungsteam. Mein damaliger „jugendlicher“ Leichtsinn trieb mich dazu, das unter dem schützenden Dach eines Generalunternehmers erprobte Arbeitsmodell auf die neu zu gründende TGA-Planungsabteilung eines freien Ingenieurbüros zu übertragen. Dies brachte weitere Herausforderungen mit sich.

Die Aufgaben und Herausforderungen für die Planungsabteilung

• Klassische Ressourcenplanung und -steuerung für zwei Teams mit je einem Teamleiter
• Ressourcenverschiebung zwischen den Teams je nach Bedarf, häufig aufgrund akuter „Feuerlöscheinsätze“
• Konkurrenzkampf zwischen uns beiden Teamleitern um Ressourcen: Wie kann ich mir die guten Leute sichern, sodass der andere sie nicht bekommt?
• Keine Bereitschaft seitens der Teamleitung, die Teams bzw. Mitarbeiter sich ihre anstehenden Aufgaben selber ziehen zu lassen
• Keine echte Vertrauensbasis zwischen uns Teamleitern und den Mitarbeitern sowie Betrachtung der Aufgabenzuteilung als Chefsache
• Vorgabe der Bearbeitungszeiten von Aufgaben durch uns Teamleiter als Basis für die Ressourcenkoordination
• Fehleinschätzung der Bearbeitungszeiten durch uns Teamleiter, fehlende Berücksichtigung der fachlichen Einschätzung der Mitarbeiter

Was hätte ich im Rückblick anders gemacht, jetzt da ich agiles Arbeiten kenne?

Im Rückblick hätte ich gemäß den Scrum-Prinzipen feste Teams mit fester Zuordnung zu einem Teamleiter gebildet, damit die Teammitglieder voneinander lernen und (zusammen-)wachsen können. Anstatt Ressourcen zwischen Projekten hin- und herzuschieben, hätten die Projekte und Teilaufgaben zwischen den Teamleitern koordiniert und priorisiert werden müssen. Die Teams hätten dann gemäß ihrer Gesamtkapazität Projekte und Aufgaben bearbeitet.Aufgaben wären somit nicht ad hoc und kleinteilig auf die Bearbeiter verteilt worden, sondern das ganze Team hätte gemeinsam Aufgaben Zug um Zug gemäß Priorisierung fertiggestellt. Es wäre Aufgabe der Teamleiter gewesen, die Priorisierung gemeinsam zu verhandeln.Durch die gemeinsame Bearbeitung von Aufgaben wären diese schneller und mit direkter Qualitäts-Kontrolle abgeschlossen worden. Dadurch wäre Last von den Schultern der erfahrenen Wissensträger genommen worden.Wir hätten daran gearbeitet, Vertrauen und Zutrauen statt Misstrauen als Basis der Zusammenarbeit im Team zu stärken. Es wäre gar nicht notwendig gewesen, Aufgaben detailliert vorzugeben, wenn statt einer Ressourcensteuerung eine inhaltliche Steuerung der Bearbeitungsfolge umgesetzt worden wäre.Schließlich hätten wir Prozesse projektübergreifend wiederholbar definieren und diese visualisieren können (z. B. mit einem Kanban-Board).

Fazit

Teamorganisation, Aufgabenverteilung und vieles mehr hätten besser funktioniert, wenn ich schon damals das Wissen über Scrum und Kanban und die Erfahrung mit agilem Arbeiten gehabt hätte. Ich bin davon überzeugt, dass agile Methoden einen ganz wichtigen Beitrag zur Organisation von Bauplanung und Planungsabteilungen sowie zur Qualitätssicherung leisten können. Und es ist an der Zeit, diesen Methoden auch in der Baubranche zu mehr Bekanntheit zu verhelfen.Meine Empfehlung lautet daher: Ingenieure und Architekten, beschäftigt euch mit Scrum und Kanban und baut Elemente davon in eure Prozesse ein!