Experten geben Tipps für agiles Arbeiten.
Culture

10 Tipps von Experten für agiles Arbeiten

Agile
Software Development

Experten erzählen aus ihrem Erfahrungsschatz. Wir haben die zehn wichtigsten Learnings für Sie abgeleitet.

Bei Greenliff arbeiten wir regelmässig in interdisziplinären Teams. Ein Beispiel ist das Projekt für die Apotheke Schaffhauserplatz. Personen aus Marketing, Design, Engineering und Testing waren daran beteiligt. Agile Zusammenarbeit ist für unsere Engineers selbstverständlich. Doch funktioniert das auch, wenn nicht alle Teams gleichermassen agil aufgestellt sind?

Um bessere Einblicke in das Thema «agile Zusammenarbeit» zu bekommen, haben wir vier externe Experten zum Interview eingeladen.

 

Sabine Neuenschwander arbeitet als agile Coach für verschiedene Mandate. In einem beeindruckenden Selbstversuch hat sie ihr privates und berufliches Leben nach agilen Grundsätzen ausgerichtet.

Peter Gfader sammelte u.a. bei Zühlke als Software Architekt und Consultant vielfältige Erfahrungen in verschiedenen Branchen und Teams. Heute arbeitet der Gründer von Beyond Agility als Scrum Trainer.

Irina Baier arbeitet der Baloise. Dort unterstützt sie Entwicklerteams als Scrum Masterin. Zuvor wirkte Irina in einer Consultingfirma in einem komplett agilen und selbstorganisierenden Setting.

Patrick Baumgartner von 42talents ist passionierter Software Crafter und Agilist. Als Dozent an der ZHAW und Organisator der Agile Breakfasts bringt er Software Themen einem breiten Publikum näher.

 

Die Grundprinzipien agiler Arbeitsweisen

 

Agilität ist mehr als eine Methode, sondern ein Thema des Mindsets. Es geht es um Transparenz, Teamwork, Feedback sowie kontinuierliche Verbesserung und Lernen. Auf diesen Grundpfeilern muss jedes Team für sich selbst definieren, was Agilität bedeutet und welche Ziele man damit erreichen will. Unter diesen Voraussetzungen ist es jederzeit möglich, als Einzelperson oder als einzelnes Team agil zu arbeiten und damit Erfolg zu haben.

Peter Gfader empfiehlt, sich an bekannten Frameworks (Scrum, Lean, etc.) zu orientieren. Er weist aber darauf hin, dass man seinen eigenen Weg finden und diesen gezielt für sich selbst oder innerhalb des Teams festlegen muss. In sogenannten «Retrospektiven» sollte man regelmässig reflektieren, was gut gelaufen ist und wo es Verbesserungspotenzial gibt. Zur Reflexion gehört zudem das Hinterfragen und Verstehen. Agil arbeiten heisst, Arbeit sichtbar machen und sich überlegen, wie man Zusammenarbeit und Produkt kontinuierlich verbessern kann.

 

Die Kommunikation zwischen agilem Team und Aussenwelt

 

(Agile) Teams arbeiten selten komplett isoliert. Es gibt Schnittstellen nach aussen. Das muss das Team in der Planung berücksichtigen. Patrick Baumgartner rät zur Kreativität: Anstatt auf die finalen Daten zu warten, arbeitet man zunächst mit Testdaten oder Dummies. So muss man nicht warten, bis andere Bereiche liefern und ist gegen Ende hin umso schneller.

«Das Team muss sich einfach bewusst sein, dass es da draussen auch eine nicht-agile Welt gibt. Die ist nicht böse oder schlecht, sondern einfach anders.»
Sabine Neuenschwander.

Das Schnittstellen-Handling ist sehr wichtig. Irina Baier rät, anderen nicht-agilen Teams mit einer wertschätzenden Haltung gegenüberzutreten. Je mehr man sie mit einbezieht und Feedback-Sessions macht, umso besser wird es. Deshalb legt sie vor allem zu Beginn eines neuen Projekts grossen Wert auf Erwartungsmanagement.

«Dinge explizit sagen und nicht implizit erwarten. So nimmt man viele (potenzielle) Konflikte vorweg. Das hat mit Agilität im eigentlichen Sinne nichts zu tun, sondern wie man zusammenarbeitet». Irina Baier

Man muss sich ausserdem bewusst sein, dass Sprache und Wording je nach Domäne unterschiedlich sind. Beispielsweise verstehen Designer und Engineers unter den gleichen Begriffen unterschiedliche Dinge. Das führt zu Missverständnissen. Ein Glossar hilft fürs Mapping und entsprechende Übersetzungen.

 

Jeder Stakeholder hat eigene Bedürfnisse

 

Stakeholder Management ist für Sabine Neuenschwander ein zentrales Thema, das jedoch häufig vernachlässigt wird. Jeder Stakeholder muss individuell informiert oder abgeholt werden. Wenn man die Bedürfnisse kennt, kann man proaktiv auf ihn zugehen. In der Regel überlegen sich Product Owner oder Scrum Master wer die Stakeholder sind und skizzieren die Zusammenarbeit.

Patrick Baumgartner empfiehlt Rapport Maps und Influence Diagrams gezieltes Stakeholder-Mapping. Ähnlich einer Landkarte zeichnet man die verschiedenen Interessen und Bedürfnisse auf. So kann man die Public Agenda und Hidden Agenda einzelner Stakeholder und / oder Teammitglieder genauer einschätzen und besser damit umgehen.

 

Die Krux mit den Entscheidungen

 

«Entscheidungen treffen» ist ein heikler Punkt. Die Rolle des Entscheiders hat Folgen. Fehler können für Projekt und Karriere fatal sein. Für Patrick Baumgartner ist jede Entscheidung ein Experiment in dem man sich zu überlegen sollte, wie hoch die Kosten sind, um diese Entscheidung wieder rückgängig zu machen. Einen spannenden Ansatz verfolgt Peter Gfader. Er setzt auf das Delegation Board. Das verschafft Klarheit darüber, wie man mit Entscheidungen umgeht und wer wofür verantwortlich ist.

Mit dem Delegation Board kann man die Verantwortlichkeit für Entscheidungen klar visualisieren.

Generell ist Peter der Auffassung, dass höhere Entscheidungskompetenz die Selbstorganisation und Motivation von Teams steigern.

«Mein grösstes Learning: Ein Team aus stark motivierten Mitarbeitern, eine klare Vision und die Unterstützung bzw. Zurückhaltung des Managements. Ist das gegeben, spielt die Methodik keine Rolle, weil die Leute sich finden und es einfach funktioniert.»
Peter Gfader

 

Den Kulturwandel agil gestalten und Zeit geben

 

Die Umstellung auf agile Arbeitsweisen ist ein Veränderungsprozess, der nicht von heute auf morgen funktioniert. Ein Kulturthema also. Irina Baier betont, dass ein Kulturwandel von oben und unten gleichermassen kommen muss. Die Mitarbeiter müssen sehen, dass es einen Mehrwert für sie hat. Dieser Prozess dauert oft Jahre.

«Ein Team hatte extrem Angst vor dem neuen Prozess. Deshalb haben sie sehr viel formalisiert und niedergeschrieben. Mit der Zeit gewannen sie Vertrauen und merkten, dass es funktioniert. Dann haben sie angefangen, diese ganze Bürokratie wieder zurückzubauen.» Patrick Baumgartner.

Sabine Neuenschwander rät, den Kulturwandel gezielt agil zu gestalten. Dies kann man systematisch angehen, indem man in einem Change Manifest beispielsweise festhält, warum man den Wandel macht, was einzelne Schritte sind und auf welchen Werten die Zusammenarbeit basiert. In regelmässigen Feedback-Runden prüft man, ob erste Fortschritte sichtbar sind.

«Wichtig ist, dass in diesem Change Projekt alle Hierarchien und Fachbereiche vertreten sind, sonst arbeiten sie später gegeneinander. Dringendst empfehle ich, die Skeptiker gezielt zu involvieren. So nimmt man ihnen den Wind aus den Segeln.» Sabine Neuenschwander

Für Peter Gfader bedeutet Kultur vor allem weg von Regeln hin zu Prinzipien. Denn Regeln funktionieren je nach Kontext manchmal besser oder schlechter. Regeln verlangen nach strikter Beachtung. Prinzipien geben Orientierung und lassen sich flexibler auf verschiedene Situationen anwenden.

Agilität findet auf ganz vielen Ebenen statt, vom Einzelnen bis hin zur Unternehmenskultur. Das sind die wichtigsten Learnings der Experten:

 

10 Tipps: Agilität scheitert, wenn…

 

… wir das Gefühl haben, wir sind agil, weil wir agile Methoden benutzen. Es muss ein Umdenken im Kopf stattfinden.

… es niemanden im Unternehmen gibt, der das vorlebt, dafür einsteht und authentisch ist.

… wir die Mitarbeiter nicht an der Vision von agilem Arbeiten teilhaben lassen.

… wir Teams nicht dazu ermächtigen, selbst Entscheidungen zu treffen und sie bei Fehlentscheidungen bestrafen.

… wir das Produkt aus den Augen verlieren und uns zu stark auf Tools und Frameworks fokussieren.

… wir Stakeholder Management vernachlässigen.

… wir kein qualitativ hochwertiges Feedback abholen, insbesondere direkt vom Markt.

… Unternehmen in Silos aufgebaut sind und Requirement Engineers, Tester, Entwickler sich Dokumente hin- und zurück schieben. Auf dieser Ebene ist kein gutes Feedback möglich.

… wir teamübergreifend nicht die gleiche Sprache sprechen.

… wir denken, Agilität sei im Rahmen eines 2-tägigen Workshops lernbar.   

 

Photo by Steven Lelham on Unsplash