Projektabwicklung Interview: agile Methoden in der Automation

Anbieter zum Thema

KEBA AG

FAULHABER SA

Agile Methoden bei der Projektabwicklung kennt man zwar schon seit mehreren Jahren. Trotzdem steht man dieser Art der Organisationsform in der Automatisierungsbranche noch skeptisch gegenüber. Bei Keba wurden allerdings bereits mehrere Projekte nach den agilen Ansätzen abgewickelt.

Man kann durchaus Verständnis dafür aufbringen, dass der klassische Maschinenbau der agilen Projektabwicklung kritisch gegenübersteht. Ein mechanisches Teil umzukonstruieren und neu zu fertigen, bedeutet schliesslich einen höheren Aufwand, als Software abzuändern. Vor allem, wenn es sich um eine einzelne Maschine oder Anlage handelt. Wie auch im Maschinenbau und damit verbunden in der Automatisierungstechnik erfolgreich mit agilen Methoden gearbeitet werden kann, erklärt Frank Weidenfelder, Vice President Platform & Technology bei Keba, in diesem Interview.

at – Aktuelle Technik: Keba führte vor einigen Jahren agile Projektmethoden nach Scrum und Kanban im Unternehmen ein. Was gab den Anstoss dazu und auf welche Art wurden diese Systeme in den verschiedenen Organisationen eingeführt und umgesetzt?

Frank Weidenfelder: Wir begannen damit schon intensiver vor über 10 Jahren. Damals hatten wir ein paar grosse Projekte in den Startlöchern.

Da es sehr umfangreiche Vorhaben waren, und damit auch mit einer mehrjährigen Entwicklungsdauer verbunden, wurde uns klar, dass klassische Methoden hier ein zu hohes Risiko bedeuten. Ein klassisches Pflichtenheft, mit einem detaillierten Blick auf Jahre voraus, hätte eine hohe Wahrscheinlichkeit gehabt, dass sich während der Entwicklung wesentliche Dinge noch ändern bzw. dass die Rahmenbedingungen sich ändern. Das kann durch Änderungen der Kundenbedürfnisse sein, aber auch die stattfindende technologische Entwicklung. Somit wollten wir den detaillierten Blick nur auf die nächste Phase werfen und die späteren Features nur grob betrachten. Genau das bieten die agilen Vorgehensweisen.

In diesen Projekten legten wir von Beginn an Wert darauf, dass alle beteiligten Personen die entsprechende Unterstützung erhalten, damit die Teams bestmöglich zusammenwirken konnten.

Wie nahm das Management die Mitarbeitenden auf die Reise der Einführung von agilem Vorgehen bei der Projektorganisation mit? War die Akzeptanz im Unternehmen von vornherein gegeben oder gab es auch interne Widerstände? Nach welchen Kriterien sind heute die Projektkreise organisiert?

Ein wichtiger Punkt war, dass klar kom­muniziert wurde, wieso wir diese me­thodischen Ansätze für diese Projekte gewählt haben. Das war auf allen Ebenen bis zum Vorstand bekannt, bzw. wurde mitgetragen.

Klar war auch, dass durch das regelmässige Controlling, mit Beteiligung vom Vorstand, natürlich indirekt auch die Methodik immer wieder Teil der Betrachtung war.

Zu Beginn begleiteten externe Berater die Kolleginnen und Kollegen der Entwicklungsteams. Jede Person dieser Entwicklungsteams absolvierte ausserdem eine Weiterbildung entsprechend der Rolle. So haben ein paar Kollegen an ScrumMaster- und Product­Owner-Schulungen teilgenommen. Und für das gesamte Entwicklerteam wurde ein eigenes Training organisiert – um sicherzustellen, dass übergreifend dasselbe Verständnis über Werkzeuge und Methodiken herrscht.

Die Teams, die damals aktiv nach agilen Methoden gearbeitet haben, waren alle sehr interessiert daran und haben auch sehr schnell die Vorteile in dem Kontext erlebt.

Heute gibt es Kreise, die einen Produktfokus/-Purpose haben. Diese arbeiten nach einem gemeinsamen Zyklus und organisieren Review- und Stakeholder-Termine. Es ist klar geregelt, welche Person im Team das Backlog organisiert. Und die Abstimmung zwischen den Teams erfolgt nach gemeinsam festgelegten Prinzipien. Was übrigens nicht bedeutet, dass jedes Entwicklungsteam nach Scrum arbeitet. Das hängt immer von den jeweiligen Aufgaben bzw. Problemstellungen ab.

Die Vorteile agiler Methoden sind so breit gefächert, dass wir dafür ein internes Schulungsangebot haben, um die wesentlichen Aspekte jeder Mitarbeiterin und jedem Mitarbeiter zu vermitteln und erlebbar zu machen.

Brauchte es dafür Umschulungen bzw. Weiterbildungen? Welche Skills bei den Mitarbeitenden mussten allenfalls gefördert werden, damit sie sich mit der veränderten Situation bei der Projektorganisation anfreunden konnten? Stichworte dazu wären z.B. dynamische Rollen im Projektkreis, verteilte Autorität sowie schnelle iterative Verbesserungen, auch gefördert durch transparente Regeln.

Zunächst ist es wichtig, dass ein Verständnis dafür entwickelt werden muss, was es überhaupt bedeutet, agil zu arbeiten. Wir beobachten immer wieder, dass manche Menschen damit ein unstrukturiertes und chaotisches Vorgehen assoziieren. Vor allem in Gesprächen mit Personen, die noch wenig Kontakt bzw. Übung mit solchen Vorgehensweisen haben.

Agil zu arbeiten, bedeutet für uns, auf Änderungen zu reagieren. Dafür müssen die Strukturen und die Abläufe Möglichkeiten für Änderungen vorsehen.

Es braucht Feedbackschleifen, um zu verstehen, wo wir stehen und Möglichkeiten Massnahmen zu setzen, wenn notwendig.

Daher gibt es ein internes Schulungsangebot in Form eines zweitägigen Workshops, wo wir mit Hands-on-Übungen erlebbar machen, was es bedeutet, agil zu arbeiten. Auch Verständnis dafür zu entwickeln, wo und wann agile Methoden von Vorteil sind und wo andere Methoden ihre Stärken haben, ist ein wesentlicher Punkt.

Wir beobachten immer wieder, dass Menschen nach einem Ausblick fragen in der Art «Wann bekomme ich die Leistung x?», und diesen Menschen wird geantwortet «Das kann ich dir nicht sagen, ich arbeite agil.». Es gibt allerdings tatsächlich sehr gute Methoden, um Forecasts zu machen, die oft besser geeignet sind als klassische Zeitschätzungen in Stunden.

Diese Methoden machen sich nämlich die menschlichen Fähigkeiten zunutze, um schnell zu Ergebnissen zu gelangen und sich nicht in Details zu verlieren, die eine Präzision suggerieren, die es nicht geben kann oder geben wird.

Dabei gibt es Klarheit darüber, welche Person welche Rolle ausübt, und was von dieser Rolle erwartet werden kann. So kann man die Stärken jeder einzelnen Person durch individuellen Rollenmix fördern. Verteilte Autorität sehen wir aus mehreren Gründen als Vorteil. Ein wesentlicher Vorteil ist, dass je nach Thema der entsprechende Könner entscheidet.

Es gab auf Kundenseite bestimmt Vorbehalte gegenüber den agilen Methoden bei ihren Projekten. Welches sind deren Vorbehalte und Gegenargumente?

Grundsätzlich sind wir sehr flexibel bei der Gestaltung der Schnittstelle zu unseren Kunden und können uns an deren Bedürfnisse anpassen. Dabei ist uns generell wichtig, dass wir ausreichend Möglichkeiten haben, mit den Kunden zu reflektieren, ob wir die Anforderungen so verstanden haben, wie der Kunde sie gemeint hat. Da dies für unsere Kunden, als auch für uns, den Vorteil eines besser passenden Produktes bringt, sind wir hier eher in der Situation, dass die gute Einbindung der Kunden als positiv wahrgenommen wird.

Zu Beginn haben wir bewusst die etablierten Schnittstellen zu Kunden nicht verändert. Wir haben intern Erfahrungen gesammelt und uns in der Arbeitsweise reflektiert und angepasst. Die Möglichkeiten, Kunden noch mehr am Entstehungsprozess teilhaben zu lassen, in Form von Zwischen-Produkten für Reviews, hat den Entwicklungsprozess für Kunden und für uns bereichert. So ist mit manchen Kunden sogar eine agile Vertragsgestaltung entstanden. Hierbei wird ein Rahmenvertrag erstellt, der in definierten Zeitabständen dann mit Vertragsbestandteilen für eine bestimmte Zeitperiode ergänzt wird. So kann auch vertraglich auf Änderungen reagiert werden.

Es gibt Fälle, bei denen agile Methoden sich weniger eignen, wie z.B. bei Projekten für Medizintechnik oder Biotech. Nach welchen Kriterien entscheidet das Unternehmen Keba, ob sich für das Projekt ein klassisches Vorgehen gemäss dem V-Modell oder Wasserfall aufdrängt. Wer wird in den Entscheidungsprozess miteinbezogen, also z.B. auch die Kunden?

Ein Faktor für die Methoden-Frage ist, ob es rechtliche Erfordernisse für die Nutzung einer bestimmten Methode bei einem Projekt gibt. So gibt es für Entwicklungen von sicherheitsrelevanten Produkten auch konkrete Anforderungen an den Entwicklungsprozess.

Diese sind auch wichtig für eine entsprechende TÜV-Zertifizierung. Hierbei wird gerne das V-Modell für Entwicklungsvorhaben vorgeschrieben.

Tatsächlich ist es gar nicht so einfach, für ein Vorhaben eine einzige Methode festzulegen. Wenn in einem Vorhaben die Unsicherheit darüber, WAS das Ergebnis sein soll, sehr gross ist und/oder wenn die Unsicherheit, WIE das Ziel erreicht werden kann, sehr gross ist, dann eignen sich agile Methoden sehr gut. Diese helfen nämlich dabei, schnell zu lernen und diese Unsicherheiten zu reduzieren.

Es gibt aber in fast jedem Vorhaben auch Aufgaben, die klar sind und geringe Unsicherheiten aufweisen. Dafür sind klassische Methoden wie Wasserfall oder das erwähnte V-Modell viel besser geeignet.

Bei Entwicklungsprojekten der Keba Industrial Automation kann es sein, dass zu Beginn eines neuen Hardwareproduktes die Unsicherheit im WAS und WIE so gross ist, dass zunächst mit zyklischen Meetings und schnellen Prototypen gelernt wird. Und wenn die wesentlichen Aspekte geklärt werden konnten, ist durchaus ein sequenzielles Vorgehen in den Fachbereichen der geeignete Ansatz. Hier könnten wir nur schwer behaupten, dass das Vorhaben nach «nur» einer Methode realisiert wurde.

Die Entscheidung und gegebenenfalls die Anpassungen danach bei Projekten treffen in der Regel der Projektleiter und der Projekt-Auftraggeber gemeinsam. Bei kleineren Tätigkeiten trifft diese Entscheidung jeder für sich. Daher ist es auch so wichtig, dass jeder im Unternehmen ein grundsätzliches Verständnis dieser Themen hat. Uns ist das so wichtig, dass es in unserer Verfassung – einem Dokument, in dem wir festhalten, wie wir miteinander arbeiten wollen, eine Entscheidungshilfe dazu gibt.

Gibt es zwei bis drei Leuchtturmprojekte, die dank agilen Projektmethoden erfolgreich und effizienter abgewickelt werden konnten? Welche Methode (Scrum, Kanban etc.) wurden verwendet und welches waren die grundlegenden Vorteile?

Ich möchte ungern Projekte gegenüberstellen, wenn der Kontext dazu fehlt. Stattdessen möchte ich unsere Keba-Organisationsform nennen. Wir arbeiten über alle Teams hinweg nach agilen Methoden und haben eine dynamische Kreis- und Rollenstruktur. Wir haben Methoden, um unsere Struktur dynamisch an Änderungen anpassen zu können.

All das hilft uns, schnell reagieren zu können. Ein Instrument, welches hierbei über alle Bereiche hinweg zum Einsatz kommt, sind die von Ihnen erwähnten Kanban Boards. Es ist ein tolles Werkzeug, um transparent zu machen, woran gerade gearbeitet wird.

Klar ist auch, dass die positiven Erfahrungen der ersten Projekte mit dazu beitrugen, agile Arbeitsweisen in weitere Teile des Unternehmens zu tragen.

In welchen Bereichen bei Keba gibt es aus Ihrer Sicht in Zukunft noch Potential für die Einführung von agilen Methoden?

Bei uns wird aufgrund der Aufgabenstellung über die Methode entschieden.

Das kann sich entsprechend dynamisch ändern. Ich sehe den grössten Hebel darin, und zwar bereichsunabhängig, weiter die eigene Arbeitsweise zu reflektieren und gegebenenfalls anzupassen. Das ist ein Prozess, der nie aufhört bzw. nie fertig ist.

(ID:50052186)