29 Nov

Adaptive Bau-Planung

Übertragung agiler Prinzipien auf die Ingenieurs-Praxis

 
Bauplan dauert lang, erstellt ein Produkt (die Bau-Planung) und unterliegt Veränderungen.
Die Bauplanung erarbeitet den Plan für den Bau. Je nach Art oder Größe des Baus und nach Anzahl und Umfang der beteiligten Personen kann sich das über einen langen Zeitraum erstrecken. Änderungen der Kunden am Bau oder auch Änderungen der Gewerke zu Materialien und auch noch viele andere Dingen können auf die Planung einwirken.
Dann müssen einzelne Dinge geändert werden, die wiederum in den Gesamt-Plan eingebunden sind. Über die Abhängigkeiten entstehen so aufwändige, teure und langwierige Änderungen am Plan. Der funktionsfähige Plan ist das Produkt.

Ein ähnliches Problemfeld hat es vor 20 Jahren in Softwareentwicklung auch gegeben – dort wurden andere Wege beschritten die mittlerweile zum „Standard“ wurden.
In der Softwareentwicklung hat vor 20 Jahren das vielerorts genauso funktioniert. Industrielle Software wurde in großen Anwendungen mit einer langen Entwicklungszeit zuerst geplant und dann erstellt. Nach der Plan-Erstellung hat es dort ebenso Veränderungen gegeben, die sich ebenso ausgewirkt haben. 2001 wurde das Manifesto für agile Software-Entwicklung festgeschrieben. Die Werte und Prinzipien haben sich dann in verschiedenen Vorgehensmodellen weiterentwickelt.

Prinzipien sind übertragbar – aber nicht kopierbar
Der Wunsch, diese (funktionierenden) Vorgehensmodelle in andere Unternehmen und auf andere Verfahren der Produkterstellung anzuwenden war sofort da. Es haben sich aber unterschiedliche Modelle herausgebildet.  Spotify hat so erfolgreich ein eigenes Modell für sich entwickelt, dass andere Unternehmen dies 1:1 kopiert haben. Der Erfolg war durchwachsen.

Am Anfang stehen die Werte – es geht NICHT mit dem Prozess los
Es muss eben jedes Team für sein spezielle Produktentwicklung die Grundwerte anwenden.
Alles beginnt bei den WERTEN für agile (flexible) Produktentwicklung die allem zu Grunde liegen. Jeder im Team und um das Team herum soll sich so verhalten, dass diese Grund-Werte berücksichtigt werden. Für die Bau-Planung schlage ich vor diese auch zu „adaptieren“ und z.B. Begriff Software zu ersetzen:
Wir gehen bessere Wege, eine Bauplanung zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionsfähige Bauplanung mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

Werte sind der Kern, jedoch sind diese nicht ausreichend für ein Team, um danach zu HANDELN, weil diese eben nicht handlungsleitend sind.

Prinzipien leiten das Handeln – die sollten auf die Bauplanung passen.
Durch möglichst einfach und klar formulierte Sätze sollen alle Beteiligten wissen wie wir arbeiten. Ich übernehme an der Stelle auch nicht die zwölf Prinzipien des agilen Manifests der Softwareentwicklung. So mache ich einen Vorschlag, der im Team diskutiert, angepasst und dann umgesetzt wird. Das Team besteht aus allen Menschen, die zusammen das Fachwissen und die Fähigkeit mitbringen um das Produkt, die Bau-Planung herzustellen. 

  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung unseres Produktes zufrieden zu stellen.
    • Früh und kontinuierlich heißt hier, eben nicht zu warten bis etwas komplett „abnahmefähig“ ist, sondern den Plan schon früher und mehrfach auszuliefern
    • Der Plan soll aber in sich funktionsfähig sein (siehe Werte) und kein halber Plan sein, sondern halb so detailliert.
  2. Anforderungsänderungen sind selbst spät in der Planungs-Phase willkommen, weil daraus ein Wettbewerbsvorteil des Kunden entsteht.
    • Wir entscheiden Dinge also so spät wie möglich
    • Dinge, die wir noch nicht ausgeplant haben, vernichten bei Änderung der Anforderung keinen Wert
  3. Fachexperten arbeiten während der Erstellung des Plans täglich zusammen.
  4. Wir stellen das Team um motivierte Menschen.
  5. Wir geben dem Team das Umfeld und die Unterstützung, die sie benötigen und vertrauen darauf, dass diese Menschen die Aufgabe erledigen.
  6. Die effizienteste und effektivste Methode, Informationen innerhalb des Teams zu teilen, ist das Gespräch von Angesicht zu Angesicht.
  7. Das Maß zur Ermittlung unseres Fortschritts ist der funktionsfähige Bau-Plan.
  8. Die Auftraggeber und das Team sollen ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
    • Wir maximieren nicht die Auslastung der Mitarbeiter.
    • Wir maximieren nicht die Effizient der Arbeiten.
    • Wir maximieren die Effektivität, in dem wir die Dinge des Produkts erstellen die den größten Nutzen für den Kunden darstellen oder aus dem wir am meisten lernen können.
  9. Einfachheit ist die Kunst, die Menge der Arbeit zu maximieren die nicht getan werden muss.
  10. Die besten Architekturen und Bau-Planungen entstehen durch selbst-organisierte Teams.
    • Wir laden solche Menschen in das Team ein, welche die Aufgabe selbst erledigen können.
    • Eine Steuerung oder Kontrolle der Arbeiten von außerhalb des Teams ist nicht nötig.
    • Eine Bewertung der Ergebnisse durch den Kunden wollen wir sehr wohl. Das nennen wir Feedback.
  11. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten selbstständig an.
  12. Wir sehen Fehler als Möglichkeit zum Lernen im Team und nicht als Mangel des Team-Mitglieds, das den Anlass zum Lernen gegeben hat.

Praktische Umsetzung erfordert das Anfangen und daraus Lernen
Viele Ideen und Methoden der Wissensarbeit könnten jetzt noch folgen, die auch direkt in der Bau-Planung eingesetzt werden könnten. Die Limitierung von Arbeiten die gleichzeitig begonnen wurden (WiP) ist sehr wichtig. Das Pull-Verfahren ist z.B. ein großartiges Prinzip, um Überlastungen von einzelnen Teammitglieder zu vermeiden und das Lernen von Team-Mitgliedern zu fördern.
Das kann aber alles gefährlich werden. Der Einsatz solcher Dinge erfordert Vertrauen in die agilen Werte und Prinzipien als auch etwas Übung. So kann ein neues Team überfordert und auch vom Wesentlichen abgelenkt werden.

Das Wesentliche ist:

  • Anfangen und Ausprobieren statt theoretisch verfeinern
  • Werte und Prinzipien im Team vereinbaren
  • Gemeinsam im Team reflektieren:
    1. Was war gut und
    2. was sollte als nächstes verbessert werden?

Dann Lernen und die nächste Iteration angehen.

Der Start in Ihrem Planer- und Ingenieurs-Team:   
Das vorhandene Planungs-Team liefert nach 2 Wochen einen ersten Plan zum Kunden (z.B. Bauherren) der in sich vollständig ist aus und fragt nach Feedback.
Das Feedback fließt ein und das Team liefert nach 2 Wochen eine neue Version des vollständigen, funktionsfähigen Plans aus.
Nach einigen Iterationen hat das Team ein Gefühl wie schnell die Qualität Ihres Produkts wächst. Der Kunde hat ein Gefühl für das Team und das Produkt.

Leave A Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.