10 Gründe, warum Sie mit Scrum scheitern

Transkript

1 10 Gründe, warum Sie mit Scrum scheitern und Tipps, wie es nicht dazu kommt! Author: Oliver Mann, Role: Agile Coach / Business Prowareness Contact: o.mann@prowareness.de,

2 Wir sind agil! Deutsche Unternehmen setzen zunehmend auf Scrum Einleitung Der Erhebungszeitraum für die Studie Status Quo Agile 2014 der Hochschule Koblenz ist seit Mai beendet. Wir dürfen gespannt sein auf die Ergebnisse. Aus der vergangenen Studie wissen wir bereits: Scrum ist vor Kanban und Xtreme Programming das mit Abstand beliebteste unter den agilen Vorgehensmodellen. Seit 2008 erlebt Scrum einen regelrechten Boom in Organisationen und wird von knapp einem Viertel der Anwender auch im Non-IT-Bereich eingesetzt. Mehr als jedes zweite IT- und Softwareentwicklungsunternehmen in Deutschland nutzt Scrum oder einen Scrum-Hybrid. Die Erfahrungen und Vorteile aus der Anwendung agiler Methoden werden von diesen Unternehmen durchweg mit gut bis sehr gut bewertet. OLIVER MANN Agile Coach / Business Consultant Mehr Informationen zur Studie: Die Anwendung von Scrum verspricht folgende Vorteile schnellere Produktentwicklung schnellere Realisierung von Änderungen in Projekten höhere Kunden-Orientierung und Nutzen- Maximierung erhöhte Transparenz über alle Prozesse und Phasen bessere Motivation und Einbindung der Mitarbeiter Vor diesem Hintergrund fällt die Entscheidung für eine Scrum Implementierung leicht. Nach unseren Erfahrungen ist es das auch. Sehr leicht tun sich damit Entwicklungs-Abeilungen / -Teams. Weniger leicht ist es manchmal auf Management- und Führungs-Ebenen, wenn agile Werte & Prinzipien nicht richtig verstanden und (vor)gelebt werden. Sich auf den agilen Pfad zu begeben bedeutet, Wandel zu akzeptieren und Mitarbeiter sowie die gesamte Organisation dabei zu unterstützen, die nötige Entwicklung durchzumachen. Dazu brauchen Sie vor allem fähige Leute auf allen Ebenen, einen guten Draht zu Ihren Kunden und eine offene, wertschätzende Firmenkultur. OLIVER MAN Oliver ist Agilist aus Leidenschaft und begeisternder Moderator mit umfassendem Fachwissen. Der Berliner mit Wohnsitz in München hat in den vergangenen 20 Jahren in verschiedenen Unternehmen und Teams als Projekt- und Senior Produktmanager gearbeitet. Dabei hat sich immer mehr seine Passion für Scrum herauskristallisiert. Oliver tauscht gern sein Wissen als Produktmanager, Product Owner und Conversion Profi aus, um Produkte und Services zu realisieren, die Sie begeistern und Ihre Kunden schlichtweg lieben! 2

3 Das ist auch der Grund für dieses Whitepaper: Sie finden im folgenden Szenarien, die wir in vielen Unternehmen vorfinden und dazu führen, dass diese nicht das volle agile Potential ausschöpfen. Übrigens sind das keine Anfängerfehler: Oft genug erleben wir solche Szenen in Firmen, die seit Jahren mit Scrum unterwegs sind... zumindest behaupten sie das. Einen Fehler machen und sich nicht bessern: Das erst heißt fehlen. (Konfuzius) So wird es nichts mit der Agilität! Begreifen und akzeptieren Sie Scrum als Stein des Anstoßes für einen fortlaufenden Change der Prozesse, Arbeits- und Denkweisen in Ihrem Unternehmen. Rufen Sie sich bitte immer wieder ins Gedächtnis, dass Sie sich aus bestimmten Gründen für Agilität entschieden haben und das es Fakt ist, dass Märkte sich ändern, Kunden sich ändern, Produkte sich ändern, staatliche wie politische Rahmenbedingungen sich ändern und es heutzutage keine erfolgversprechende Überlebensstrategie sein kann, all das zu ignorieren und das Unternehmen nicht anzupassen. 1. Lange Entwicklung, kaum Änderungen Sie müssen agile Methoden nicht in jedem Projekt und für alle Vorgänge einsetzen. Scrum ist in gewisser Weise streng und verlangt viel Disziplin. Es ist aber auch dafür gemacht, in komplexen Umgebungen mit vielen Abhängigkeiten und vielen Änderungen agieren und regelmäßig hohe Qualität liefern zu können. Sie brauchen Scrum nicht, wenn sich in Projekten nur wenig ändert, sie geringe oder gar keine Abhängigkeiten haben und es auf die Einhaltung bestimmter Liefertermine gar nicht so ankommt. Kurzum: Ist ein Projekt absolut überschaubar und stets mehr bekannt, als unbekannt, brauchen Sie Scrum nicht zwingend. 2. Scrum Basics werden nicht beherrscht Scrum ist leichtgewichtig und einfach zu verstehen. Nach zwei Tagen professionellem Training können Sie anfangen zu scrummen oder sich selbst über agile Veranstaltungen und Fachbücher einlernen. Dennoch müssen wir aus unserer Erfahrung heraus sagen, dass wir es in Unternehmen erleben, dass wesentliche Grundlagen nicht beherrscht werden. Zum Beispiel, wenn nicht alle Elemente von Scrum eingesetzt werden, sondern nur einzelne, die bequemen Teile. Hier ist in erster Linie ein gut ausgebildeter Scrum Master mit guten Moderations-Skills gefordert darauf zu achten, dass Scrum richtig und effektiv eingesetzt wird. Meeting-Kultur: Es bringt nichts, den Tag in unvorbereiteten Meetings ohne klare Agenda zu verbringen bei der jeder nur seine Meinung sagt. Endlose Diskussionen um den heißen Brei sind nicht produktiv. Sie brauchen klare Struktur, Moderation und Time-Boxen. Jedes Meeting fängt pünktlich an und hört zur vorgesehenen Zeit auf. Abteilungs- und Hierarchie-Denke: Scrum kennt nur Rollen (Scrum Master, Product Owner, Stakeholder). Keine Positionen. Es geht in der agilen Welt um Kollaboration bei gegenseitigem Respekt, Offenheit sowie Transparenz in allem was geschieht. In solch einer Umgebung kann Verantwortung von jedem einzelnen übernommen werden. Sie können Probleme ansprechen, wenn etwas aus dem Ruder oder Budget zu laufen scheint und gemeinsam an konkreten Lösungen arbeiten. Nicht meine Abteilung! Dafür bin ich nicht zuständig! Das ist Sache des Kollegen. stimmt nur bedingt. Sie alle arbeiten zusammen für die höheren Ziele im Unternehmen. Sprechen Sie Dinge offen an, geben Sie anderen Einblicke in Ihre fachkundigen Sichtweisen und der Kollege erkennt womöglich jetzt erst das Problem und kann an der Lösung arbeiten. Kunde im Sprint und Review nicht dabei: Sie entwickeln nicht zum Selbstzweck. Sie haben einen Auftrag von ganz konkreten Personen mit relativ konkreten Vorstellungen zum Endergebnis. Auch wenn Sie im Vorfeld über vieles gesprochen und einiges vereinbart haben, es kommt immer zu Situationen, in denen der Kunde Änderungen möchte oder das Entwicklungsteam erkennt, dass Funktionalität nicht wie angenommen geliefert werden kann oder doch deutlich komplexer wird. Darum ist der regelmäßige Austausch zwischen Team und Auftraggeber wichtig. Darum muss der Auftraggeber im Review am Ende eines Sprints dabei sein. Gemeinsam schauen Sie auf das fertige Produkt-Inkrement, gemeinsam schauen Sie drauf, was noch zu liefern ist und welche Änderungen oder Ergänzungen es womöglich gibt. Regelmäßiges Feedback ist wesentlicher Bestandteil agiler Vorgehensweisen. Besteht kein Interesse am Austausch, ist das Produkt womöglich nicht so wichtig oder Ihr Stakeholder ist nicht die eigentliche Interessens-Person. 3. Keine klaren Ziele Stellen Sie sich vor, Sie sind auf Wanderung und suchen den Weg zu einer Berghütte, die Ihnen wegen der tollen Aussicht und des guten Essens empfohlen wurde. Das Problem ist nur, Sie stehen an einer Wegkreuzung und können mehrere Richtungen einschlagen, doch ein Wegweiser zur gesuchten Hütte fehlt. 3

4 Ganz ähnliche Situationen erleben Sie tagtäglich in der Firma: Wenn Organisationen ohne klar formulierte Ziele unterwegs sind, wenn Teams ohne Sprint-Ziel loslegen, kann die Reise tendentiell in jede Richtung gehen. Die Konsequenz daraus ist: Es wird auch jede Richtung eingeschlagen. Man fängt an rumzueiern um überhaupt den richtigen Weg zu finden. Das kostet Zeit, Geld und Nerven. Sie beheben das, indem Sie sich als Organisation u.a. Klarheit über folgende Punkte verschaffen: Was ist Sinn und Zweck dieses Unternehmens? Auf welchen Märkten sind wir aktiv? Auf welchen nicht? Wer sind unsere Mitbewerber? Worin sind diese besser/ schlechter? Wer sind unsere Kunden? Was sind ihre Bedürfnisse? Wie und womit können wir diese Bedürfnisse befriedigen? Ist unsere Organisations-Struktur dazu fähig? Sind unsere Mitarbeiter dazu fähig? Gibt es Alternativen zu Dingen, die uns aktuell fehlen? Auch Scrum-Teams brauchen Ziele. Eine übergreifende Produkt-Vision sowie Teilziele für jeden einzelnen Sprint. Das gut gepflegte Product-Backlog des Product Owners ist ein hervorragender Ausgangspunkt, um den Blick für das große Ganze und Teilziele abzuleiten, die sich dann in einer Roadund Releasemap konkretisieren lassen. 4. Mangelnde Transparenz Wofür mach ich das hier eigentlich? Wann haben wir die grundlegenden Features für den ersten Release fertig? Schaffen wir es, alle Features tatsächlich bis Q4 fertig zu stellen? Was wird im aktuellen Sprint entwickelt? Werden wir alle Features wie geplant in den nächsten 2 Wochen fertig stellen? Was denken unsere Kunden über unser Produkt? Wie gut verkauft sich unser Produkt am Markt? Der Fragen-Katalog ist lang, aber berechtigt. Jeder Projektbeteiligte verfolgt teils eigene Interessen und hat seine eigenen Sichtweisen und Fragen. Indem Sie den Dialog Ihrer Mitarbeiter und Teams fördern, Ziele kommunizieren, Dailys abhalten, Reviews machen, Team-Retrospektiven machen, einsehbare Sprint- und Kanban-Boards aufhängen, Sprint-Reports sharen schaffen Sie Transparenz und tauschen ganz selbstverständlich Informationen aus. Nicht missverstehen: Es geht nicht um Kontrolle. Verantwortungsvoll handelnde Menschen müssen nicht kontrolliert werden. Sie sollten sich aber jederzeit und auf jeder Ebene ein Bild davon machen können, ob es in der Sache also im Projekt richtig läuft oder nicht. 5. Fehler sind nicht zulässig In einem System, das auf reine Wert-Maximierung bei Einsatz möglichst geringer Ressourcen aus ist, sind Fehler hinderlich. Fehler die spät erkannt werden, führen zu zwingend notwendigen Änderungen. Je später Sie etwas ändern müssen, umso teurer wird es. Es klingt verständlich, dass man Fehler vermeiden möchte und deswegen auch einen Großteil der Planung auf Kosten und Risiko-Betrachtungen lenkt. Merkwürdig, denn jedem Kind geben wir den Rat: Aus Fehlern lernst du. Wenn du keine Fehler machst, wie sollst du dann die Erfahrungen machen, was richtig oder falsch ist? - Eben! Nun sind etablierte Firmen den Kinderschuhen hoffentlich entwachsen, doch ich möchte noch verschärfen: Du musst Fehler machen, sonst lernst du nichts! Rapid Prototyping, Xtreme Programming, Hacknights, User-Testing, Automated Testing, etc und alle Events in Scrum dienen in agilen Umgebungen dem Zweck, Feedback zu erhalten, Fehler frühzeitig zu erkennen und rechtzeitig Änderungen herbeizuführen. Welcome changes early and often, even late in development ist eines der wesentlichen agilen Prinzipien. Sie sollten es schlichtweg akzeptieren, dass Dinge sich ändern, dass Fehler passieren und dies nicht als Scheitern bewerten, sondern eine Umgebung und Kultur schaffen, in der es erlaubt und sogar willkommen ist, Fehler zu entdecken und darauf entsprechend zu reagieren. Genau das wollen Sie doch: Mitarbeiter, die mitdenken. Die Software auf Fehler überprüfen und Ihre Ideen einbringen, weil sie durch automatisierte Test- und Release-Umgebungen Zeit dafür haben, sich fachlich einzubringen, damit Sie die Anzahl an Defects reduzieren. Damit Sie ein qualitativ hochwertiges, performantes und stabiles Produkt beim Kunden ausliefern. Das geht nicht, wenn Sie die Fehler und Eigenheiten des Systems nicht kennen. 6. Falsche Rollenbesetzung Natürlich stellt sich die Frage, welche Personen im Unternehmen geeignet sind, die Rolle des Scrum Masters oder Product Owners einzunehmen. Was mit Sicherheit schief geht ist, wenn Sie einen Team- oder Projekt-Leiter nehmen und ihn dem Team als Scrum Master zur Seite stellen. Das Team wird nicht verstehen, warum ihr Chef nun keiner mehr ist und trotzdem aus dem gewohnten Verhalten heraus alle Verantwortung auf den Scrum Master abwälzen. 4

5 Ein Scrum Master ist in erster Linie ein Unterstützer (Facilitator) für das Team. Er hat ein Auge auf die Prozesse und hilft dabei, dass Scrum vom Team wie auch der Organisation verstanden und entsprechend angewendet wird. Er sorgt für die Durchführung und Einhaltung der essentiellen Events und wird bei der Moderation helfen. Er wird auch helfen, Hindernisse zu beseitigen, die das Team davon abhalten, ihre Arbeit zu tun. Aber er ist nicht verantwortlich für die Inhalte, die ein Team liefert. Was und wie es entwickelt wird, liegt in der Verantwortung des Product Owners (Was wird umgesetzt?) gemeinsam mit dem Team (Wie wird etwas umgesetzt?). Ebenso wird es selten funktionieren, dass Sie einen Lead-Developer zum Scrum-Master machen. Er hat oft das meiste Know-How und viele Dinge allein gemacht. Er wird sich schwer damit tun, immer weniger zu entwickeln und stattdessen vielmehr zu managen. Ein Team zu managen verlangt gänzlich andere Skills. Ein guter Scrum Master löst daher nicht die Probleme für das Team, indem er alles selbst macht. Er leitet es an und unterstützt es dabei, die Lösung effektiv selbst zu entwickeln. Es kann gut funktionieren, dem Team einen Scrum Master aus einem anderen Team oder einer anderen Abteilung zur Verfügung zu stellen und umgekehrt. Diese Personen sind objektiver und den Teams schon bekannt. Sie sind bereits respektiert und in ihrer Rolle schneller akzeptiert. 7. Rollen als Teilzeit-Job Gerade bei der Einführung von Scrum im Unternehmen sollen Sie eisern dabei bleiben: Pro Team ein Scrum Master und ein Product Owner. Beide jeweils nur für das entsprechende Produkt oder Teilprodukt und zwar als Vollzeit-Rolle! Wenn Sie richtig gut laufende Scrum Teams haben, die eigenständig und eigenverantwortlich Ihre Meetings abhalten und regelmäßig in Abstimmung mit dem Product Owner liefern, kann es gut sein, dass der Scrum Master dieses Teams auch noch ein anderes oder weitere Teams betreuen kann. Was aber erfahrungsgemäß sicher in die Hose geht ist, wenn ein Product Owner mehrere Teams oder Projekte managen soll. Ein Product Owner hat schlichtweg mit einem Team, Stakeholdern und Produkt soviel zu tun, dass er nichts anderem zusätzliche Aufmerksamkeit schenken kann. Wie sollte ein Product Owner gleichzeitig an zwei Sprint- Plannings teilnehmen? Wie sollte er für Team A für Fragen zur Verfügung stehen, wenn er gerade mit Team-B in einem Backlog-Refinement-Meeting sitzt? Wie sollte er am Review- Meeting teilhaben, wenn das andere Team ihn gern in ihrer Retrospective hätte? es gibt unzählige Beispiele dafür, dass es nicht klappen wird. Unsere dringende Empfehlung ist: Pro Produkt ein Product Owner (auch nicht zwei oder mehr!) 8. Ignoranz gegenüber agilen Werten In keinem Buch, Training, Coaching und in keiner Zertifizierung werden Ihnen NICHT die agilen Prinzipien und das agile Manifest eingebläut. Jeder erkennt auch schnell den Sinn und vereinbart sich damit. bis es in der täglichen Praxis in Vergessenheit gerät oder gar vom Management ignoriert wird. Lesen Sie dazu bitte einmal das Agile Manifest: agilemanifesto.org/iso/de/ und die zwölf Prinzipien agiler Softareentwicklung: agilemanifesto.org/iso/de/principles.html und vergleichen die Aussagen mit folgenden Beispielen, die wir original so erlebt haben: Wir nutzen jetzt MS Project und Trac im gesamten Unternehmen. Das hat die Geschäftsleitung entschieden. Ihr müsst euer Jira einstellen. Ich release schon immer über drei Stages. Gut, das dauert und ist viel manueller Aufwand. Aber ich kann das und es funktioniert ganz gut bisher. Der Product Owner möchte, dass wir im nächsten Sprint eine neue Funktion entwickeln. Seh ich gar nicht ein, wir wollten doch erst noch die GUI-Überarbeitung fertig stellen. Wir sehen ja ein, dass unseren Leuten ein wenig die Skills für die Entwicklung des Services fehlen. Aber wir haben grad keine anderen Entwickler und die können sich doch einarbeiten in die Materie. Der Kunde will seine Software schon produktiv einsetzen wenn das nächste Modul fertig ist. Dabei haben wir doch noch sechs weitere geplant. 9. Lost in Management und Reports Wenn Sie sich für Scrum entscheiden, entscheiden Sie sich dafür, dass manches künftig anders läuft. Sie beginnen mit einem Change Prozess. Akzeptieren und kommunizieren Sie diesen Umstand. Reden Sie darüber, was sich ändern wird und machen Sie es transparent. Visualisieren Sie. Und am allerwichtigsten: Denken Sie um, trennen Sie sich von alten Zöpfen. 5

6 Sie sitzen in immer mehr statt weniger Meetings? Sie müssen ständig Prognosen und Reports abliefern, aber keiner hat überprüft, wo das Zahlenwerk herkommt und ob es in der Form noch hilfreich ist? Sie verbringen viel Zeit damit, Zahlen, Daten, Fakten von unterschiedlichen Leuten und Abteilungen für wöchentliche und monatliche Reports für irgendwelche Leute zusammenzutragen? Sie springen zwischen mehreren Projekten, aber keines kommt je wirklich zu einem Ende? Sie haben ein Projekt fertiggestellt, aber seither nichts darüber gehört, wie gut es ankam? Wenn Sie agil werden, krempeln Sie früher oder später Ihr Unternehmen um. Sie verändern Prozesse und Workflows ebenso wie das Reporting. Sie übertragen mehr Verantwortung auf jeden einzelnen und benötigen daher keine Kontroll-Reports mehr. Ihre Teams arbeiten transparent und zeigen im Review, was sie erreicht haben. Ihre Product Owner arbeiten mit Stakeholdern und Kunden zusammen und können jederzeit Auskunft geben, welche Funktionen und Services gewünscht und wichtig sind. Das bedeutet nicht, dass sie gar keine Reports und kein Management mehr brauchen. Es bedeutet aber, dass sich die Management-Aufgaben und -Zahlen ändern. Scrum can be used to manage the change management. (Zitat Gunther Verheyen, Scrum Day Europe 2013) Agilität wird für die meisten Unternehmen zum kritischen Überlebensfaktor. Knapp 40% befragter Unternehmen sehen das bereits heute so. Aber nur 20% dieser Unternehmen sind bereits zu 100% agil. Der Agility-Path der Scrum.org und Veranstaltungen wie der Scrum Day Europe geben einen Überblick und Antworten, wie Sie mit den veränderten Bedingungen umgehen. Welche KPI s (Key Performance Indicators) Sie benötigen, um auf Management-Ebene den Change anzustoßen, zu begleiten und zu steuern. Scrum is not the answer. Scrum is an enabler. (Ken Schwaber, scrum.org) Mehr Informationen: wenn Sie etwas ändern. Entwicklungen an der Börse und in der Politik zeigen das tagtäglich. Da Sie eigentlich nicht wissen, was morgen passiert kann es auch schlecht funktionieren, dass man sich zum Beispiel nur am Wettbewerb orientiert und deren Ideen und Lösungen kopiert. Sie fokussieren damit auf die Konkurrenz, sehen aber nur deren Produkt an der Oberfläche und kennen weder den Einsatz noch die Opfer, die sie bringen mussten. Auch wenn Sie den Blick nach innen gewendet haben und ein neues Projekt angehen, sollten Sie aufpassen, nicht in die Falle zu tappen anzunehmen, Sie wüssten bereits wie sich Ihr Produkt verhält, wie es beim Kunden ankommen und sich verkaufen wird. Egal wie viel Erfahrung Sie aus vorigen Projekten mitbringen: gehen Sie davon aus, dass Sie mit jeder Änderung neue Erfahrungen machen werden. In agilen Organisationen entwickeln Sie Lösungen aufbauend auf bisherigen Erfahrungen. Sie schätzen Risiken und Aufwände basierend auf bisher erreichtem ein und auch basierend auf den Leuten und ihren Skills, die Sie tatsächlich zur Verfügung haben. Auch hier wissen Sie nicht, was morgen vielleicht passiert. Aber aus diesem Grund testen und liefern Sie in kurzen und frühen Phasen und etablieren eine Umgebung, in der schnelles und flexibles handeln möglich wird und auf maximal mittellange Zeitspannen fokussiert wird. Hilfe / Anregungen? Ich hoffe, Sie haben einige Anregungen bekommen, die Sie in der Praxis nutzen können. Wenn Sie Fragen haben oder Hilfe brauchen freue ich mich über eine Mail oder Anruf von Ihnen. Treffen Sie mich auf einem unserer regelmäßigen Austausch- Veranstaltungen, dem Prowareness Agile+Market oder anderen agilen Events. Aktuelle Infos und Termine erhalten Sie über die Website Danke für Ihr Interesse an diesem Whitepaper Oliver Mann, Agile Coach Wenn Sie Fragen haben oder Feedback geben möchten, schreiben Sie mir an o.mann@prowareness.de 10. Copy & Paste klappt nur bedingt Sie entwickeln komplexe Produkte in komplexen Umgebungen. Aus der Systemtheorie wissen wir, dass Sie in solchen Umgebungen nicht vorhersagen können, wie sich das System verhalten wird. Schlimmer noch: Sie können erst recht nicht vorhersagen, wie sich das System verhalten wird, 6