5 Fragen zur Einführung von Scrum

Organisationen werden nicht durch Zauberhand von heute auf morgen agil. Es ist ein bedeutsamer Wandlungsprozess, bei dem jede Person ihre Rolle überprüfen und anpassen muss. Und alles fängt damit an, dass die Führungsebene einige recht komplizierte Fragen beantworten muss.

Aufgrund der Herausforderungen, denen sich moderne Organisationen stellen müssen, ist Agile äußerst verlockend. Wer würde nicht gerne häufigere Releases haben? Wer würde sich nicht gerne besser an ein sich ständig veränderndes Geschäftsumfeld anpassen können? Zu viele Führungskräfte ziehen Scrum jedoch in Erwägung und beginnen eine agile Transformation, ohne ein Verständnis für die Auswirkungen zu haben, die Scrum auf ihre Organisation, ihre Karriere und ihre Ziele haben kann.

Scrum ist nichts, was leichtfertig in eine Organisation eingeführt werden sollte, und die Führungskräfte sollten sich einige komplizierte Fragen stellen. Scrum ist nicht nur Sache der Entwicklungsteams. Es kann nicht nur auf ein einzelnes Team beschränkt werden. Die Einführung von Scrum stellt eine systematische Veränderung in einer Organisation dar und wird regelmäßig als schwierig und störend beschrieben. Aber was bedeutet das wirklich? Was sind mögliche Auswirkungen von Scrum?

Hier sind fünf Fragen, die beantwortet werden sollten, damit man sich auf eine erfolgreiche und produktive Einführung von Scrum vorbereiten kann.

1) Wie reagiere ich auf Veränderungen, die meine Rolle beeinflussen?

Diese Frage muss von allen Personen in einer Organisation beantwortet werden und nicht nur von den Teams, die mit Scrum arbeiten sollen. Den direktesten Einfluss hat Scrum auf die Teams; damit hört es aber nicht auf. Was ist mit den Vorgesetzten? Und wie werden Sie wohl reagieren, wenn Ihre Führungsrolle dadurch beeinflusst wird?

Beispiel: Scrum und das mittlere Management

Ich saß mit meinem Freund John (Name geändert) beim Frühstück. John war ein Entwicklungsmanager bei einem großen Finanzdienstleister, wo Scrum in den letzten Jahren eingeführt worden war.

Er machte sich Sorgen darum, wie seine Rolle in dem Unternehmen nun gesehen würde. Ich fragte ihn, warum er besorgt sei, und er antwortete, „am Anfang war alles gut. Die Teams machten schnell Fortschritte und ein teambasiertes Arbeitsumfeld ist für die Leute besser geeignet als ein Shared-Services-Modell. Jetzt haben wir aber Teams, die ihre Probleme größtenteils selber lösen und selbst ihre Leistung überwachen.”

Er wollte wissen, was seine Rolle in diesem neuen selbstorganisierten Umfeld war.

Die Funktion von mittleren Managern in Unternehmen, die an das „Scientific Management”-Modell (Taylorismus) angelehnt sind, dreht sich hauptsächlich um die Leistung und Effizienz der Angestellten. Dem Taylorismus wird ein Großteil der Produktivitätssteigerung des 20. Jahrhunderts zugeschrieben. Allerdings ist es weniger gut für die Erschaffung von modernen und wissensbasierten Produkten geeignet.

Wie verändert sich also die Rolle des mittleren Managements bei der Einführung von Scrum?

Nach einer kurzen Diskussion entschied John, dass er etwas beitragen kann, indem als Mentor und Kommunikator für seine Teams fungiert, ihnen zeigt, was von der Unternehmensseite her benötigt wird, und indem er dem Unternehmen zeigt, dass seine Teams diese Bedürfnisse erfüllen können.

2) Wie gehen Sie mit Ihren Top-Mitarbeitern um, wenn sie nicht mit auf diese Reise gehen wollen?

Nicht jeder möchte mit Scrum arbeiten. Vielen Leuten gefällt Scrum, weil es ihnen erlaubt, ein Produkt zu erschaffen, auf das sie einen direkten Einfluss haben, und das kann sich sehr gut anfühlen. Aber nicht jedem wird es so gehen.

Beispiel: Der verärgerte Star

Jack war der Star in seinem Team und das ließ er auch jeden wissen. Wenn es für das Team auf eine Deadline zuging, arbeitete Jack oft 80 Stunden pro Woche, damit das Team sein Ziel erreichte. Oft war er noch um 22:00 im Büro und schickte der Geschäftsleitung sogar am Wochenende E-Mails. Das Management liebte ihn!

Die Qualität seiner Arbeit war allerdings fragwürdig. Er produzierte viel Code, der nicht funktionierte und erhebliche Überarbeitung erforderte. Nach einer weiteren durchzechten Nacht im Büro hatten die anderen Teammitglieder tagelang damit zu tun, seinen Code von Fehlern zu befreien und zu integrieren.

Sie versuchten, Jack zu erklären, dass sein Verhalten das ganze Team beeinträchtigte – aber er wollte nicht hören und sagte, „klärt das mit dem Management”.

Die Situation änderte sich, als Scrum bei diesem Team eingeführt wurde. Der Fortschritt und die Transparenz im Team wurden jeden Tag während des Daily Scrums besprochen – der tägliche Fortschritt wurde also permanent vom Team gemessen. Dadurch, dass das Team selbst entscheiden durfte, wie viel Arbeit sie in einer Iteration fertigstellen würden, konnten sie während des gesamten Projekts mit einem nachhaltigeren Tempo arbeiten.

Während einer Retrospektive hinterfragte das Team das Erstellen von nicht vollständig getestetem Code, der dem gesamten Team Zeit raubte.

Jack nahm die Einführung von Scrum nicht gut auf. Die gute Transparenz im Daily Scrum unterstrich ganz eindeutig, dass Jack nicht regelmäßig Code lieferte, sondern die Arbeit bis zum letzten Tag des Sprints aufschob. Als das Team Vorschläge zur Problemlösung lieferte, beklagte sich Jack über Mikromanagement.

Er kam nicht damit klar, mit einem konstanten und nachhaltigen Tempo zu arbeiten, und anstatt sich auf den größten Wert für den Kunden zu konzentrieren, beschwerte er sich darüber, dass seine Arbeit „langweilig” oder „keine Herausforderung” sei.

Als das Team sich während einer Retrospektive dazu verpflichtete, die Qualität des Codes durch regelmäßige Tests zu verbessern, drohte Jack damit, das Team und sogar das Unternehmen zu verlassen. Fünf Sprints nach der Einführung von Scrum verließ Jack das Unternehmen freiwillig. Die Leistung des Teams verbesserte sich stetig und drei Jahre später produzierten sie immer noch ein qualitativ hochwertiges Produkt.

Bei der Einführung von Agile müssen sich die Unternehmen überlegen, was geschehen soll, wenn ihre Top-Mitarbeiter nicht in einem Scrum Team arbeiten möchten. Würden Sie sie gehen lassen? Oder sollten sie in dem Unternehmen bleiben und eventuell andere Scrum Teams stören? Wenn Sie bereit sind, sie gehen zu lassen, wie begründen Sie diese Entscheidung dann?

3) Welche Mechanismen werden Sie nutzen, um Verhaltensänderungen herbeizuführen?

Scrum erfordert Verhaltensänderungen; dazu gehören Selbstorganisation, vermehrte Zusammenarbeit und Transparenz. Verhaltensweisen zu ändern, ist extrem schwierig, besonders für langjährige Mitarbeiter, die darauf trainiert wurden, sich auf eine bestimmte Art und Weise zu verhalten. Wie stellen Sie jetzt, da eine Veränderung erforderlich ist, sicher, dass das auch wirklich geschieht?

Kontinuierliche Weiterbildung spielt hier eine große Rolle.

Als Führungskraft im Management kann man die Mitarbeiter mit Trainings, Coaching und Konferenzen unterstützen und ihnen helfen, die modernen Methoden der Softwareentwicklung zu verstehen und anzuwenden. Und indem man Engagement für die Mitarbeiter zeigt, kann sich die Moral und Zufriedenheit der Angestellten sowie des Unternehmens verbessern.

Ein wesentlicher Teil dieser Verhaltensänderung hat mit Vertrauen im Team zu tun. Wenn ich mit jemandem zusammenarbeite und derjenige meinen Job versteht, ist das dann ein Risiko für meine Leistungsbewertung? Ist es ein Risiko für meinen Job? Wie lässt sich Vertrauen aufbauen, wenn eine der beiden Fragen mit „Ja” beantwortet werden kann?

Ein gängiger Ansatz ist es, die Verantwortlichkeiten und Kennzahlen zu verändern, anhand derer die Mitarbeiter bewertet werden. Um kooperatives Verhalten zu fördern, wird dem Teamwork mehr Gewicht beigemessen als der Leistung von einzelnen Personen. Das kann mit dem teambasierten bzw. 360°-Feedback geschehen.

Auf die Leistung einzelner Personen weniger Wert zu legen, stellt individuelle Verantwortlichkeiten infrage. Niemand möchte für einen bestimmten Bereich verantwortlich sein, wenn er anhand der Leistung des gesamten Teams beurteilt wird. Daher sollten Mitglieder von Scrum Teams natürlich Verantwortung für verschiedene Bereiche übertragen bekommen. Das bedeutet, dass sie in jedem Sprint einen Teil eines potentiell lieferbaren Produkts liefern sollten.

Das mag unbedeutend erscheinen, hat aber große Auswirkungen darauf, wie ein Unternehmen agiert. Wie beeinflusst es Ihre Organisationsstruktur, wenn die Teams für die Arbeit in mehreren unterschiedlichen Themenbereichen verantwortlich sind?

4) Wie wird die Support-Abteilung über die von Scrum hervorgerufenen Veränderungen denken?

Scrum wird in den meisten Fällen durch Softwareentwicklungsteams in eine Organisation eingeführt. An Support- und Architekturteams wird dabei im Voraus selten gedacht. Das liegt daran, dass viele Organisationen annehmen, dass „Scrum etwas ist, das Entwickler machen”.

Tatsache ist aber, dass Scrum definitiv auch andere Teams beeinflusst. Wie werden Support-Teams beispielsweise reagieren, wenn es Reibungspunkte mit den Scrum Teams gibt. Wie werden diese Probleme dann gelöst?

Beispiel: Unstimmigkeiten zwischen verschiedenen Abteilungen

Sarah war eine leitende Java Messaging Service (JMS) Architektin und für die unternehmenseigene Vision eines Enterprise Service Bus (ESB) zuständig. Sie wurde zunehmend frustrierter, weil die Scrum Teams „die Unternehmensleitlinien ignorierten, indem sie entweder den ESB umgingen oder neue Features hinzufügten, die nicht auf die Unternehmensstrategie angepasst waren”.

Als man sie fragte, warum die Teams sich wohl so verhielten, meinte sie, die Teams bräuchten mehr Disziplin und eine bessere Schulung bezüglich der ESB-Strategie. Und dann fügte sie noch hinzu, „vielleicht erfüllen wir aber auch nicht ihre Anforderungen”.

Nach weiterer Erörterung entschied Sarah, dass es wohl am besten sei, einem Scrum Team beizutreten, um deren Herausforderungen verstehen zu können und ihnen zu helfen, die Unternehmensziele besser zu verstehen.

5) Was ist das Unternehmen bereit, für diese Transformation auszugeben? Und welcher Wert wird für diesen Aufwand geliefert?

Nur wenige Unternehmen haben vorab eine klare Vorstellung davon, wie viel sie ungefähr mit Agile verdienen werden. Es gibt nur wenige Informationen dazu, wie viel Umsatz man etwa erwarten kann. Allerdings gibt es immer wieder Beweise dafür, dass man mit Scrum häufigere Releases, bessere Produktqualität und direkteren Kontakt zu den Kunden erreichen kann.

Eine gute Lösung dafür ist ein fixes jährliches Budget für permanentes Training und Coaching der Mitarbeiter. Das wird allerdings problematisch, wenn die Einführung von Scrum schneller voran geht, als das Budget erlaubt. Es ist auch schwer zu rechtfertigen, wenn man nicht klar sagen kann, wie viel Umsatz dadurch erwirtschaftet wird.

Eine bessere Lösung wäre das Messen einiger wichtiger Kennzahlen, wie z. B.:

• Umsatz pro Mitarbeiter
• Kundenzufriedenheit
• Mitarbeiterzufriedenheit
  Wenn die Führungskräfte beobachten, ob sich diese Kennzahlen durch Scrum verbessern, können sie sehen, wie effektiv die Einführung von Scrum ist und ob man etwas verändern muss.

Es gibt jedoch ein paar interessante Dinge bei diesem Lösungsansatz, die es wert sind, hervorgehoben zu werden:

Erstens ist diese Methode unabhängig von dem Framework, das genutzt wird, und könnte auch die Leistung eines Unternehmens messen, das nicht mit Agile arbeitet. Zweitens finden Sie vielleicht heraus, dass Scrum nicht der beste Ansatz für Ihr Unternehmen ist oder dass es effektivere Frameworks als Scrum gibt. Das kommt selten vor, ist aber natürlich möglich.

Eben diesen Messansatz hat Ken Schwaber kürzlich in seinem „Evidence-Based-Management” (dt.: evidenzbasiertes Management) aufgegriffen. Es ist noch zu früh, um sagen zu können, welchen Einfluss dieser Ansatz auf die Softwareentwicklung haben wird, aber es ist eine sehr interessante Lösung und hat das Potential, den Unternehmen konkrete Beweise für ihre Verbesserung zu liefern.

Das Fazit

Scrum einzuführen, ist nichts, was leichtfertig geschehen sollte. Es besteht sowohl ein Risiko für die Organisation als auch für die einzelnen Personen. Wenn man die Fragen versteht, die Leute stellen, wird man deren Motivation, Ängste und Zweifel besser nachvollziehen können. Und mit diesem Wissen kann man einen viel umfassenderen Ansatz formen können, der auf die Bedürfnisse des Unternehmens und der Mitarbeiter eingeht.

„Die Fähigkeit, logisch zu denken, ist eines der Dinge, die uns als Mensch ausmachen. In einer Welt allgegenwärtiger Informationen und hochentwickelter Analyse-Tools reicht Logik alleine jedoch nicht aus. Was die erfolgreichen Menschen hervorheben wird, ist ihre Fähigkeit, sich in ihre Mitmenschen hineinversetzen zu können, Beziehungen aufzubauen und sich um andere zu kümmern.”
– Daniel H. Pink, Bestseller-Autor von Drive

(Anmerkung: Dies ist ein Gastbeitrag von Scrum Trainer und Coach Kane Mar, dem Gründer von Scrumology.com und Scrum101.com.) Dieser Text stammt aus dem Blog von Openview und wurde von uns ins Deutsche übersetzt.