Das Scrum-Prinzip

Agile Organisationen aufbauen und gestalten

Boris Gloger, Jürgen Margetich

• Verlag: Schäffer-Poeschel
• Jahr: 2018
• Auflage: 2
• eBook-ISBN:
  9783791039497
• Thema: Business
• Thema: Management

Die Prinzipien von Scrum verleihen einem Unternehmen die vielleicht wichtigste Fähigkeit, um in der heutigen Welt erfolgreich wirtschaften zu können: Agilität. Selbstorganisierte Teams erzielen überdurchschnittliche Ergebnisse mit Hilfe weniger, aber klarer Regeln und Methoden: - Konsequente Lösungsorientierung- Klare Verantwortlichkeiten- Einbindung des Nutzers- Flexible Plananpassung- Flache HierarchienDie Autoren arbeiten Scrum als Prinzip der Organisationsentwicklung auf und liefern damit ein grundlegendes Praxishandbuch für Manager und Change Manager. Der Praxisleitfaden zeigt, wie Scrum in Organisationen Schritt für Schritt integriert werden kann.In der 2. Auflage neu: - Agilität - vom Hype zur Notwendigkeit- Scrum als Management-Prinzip - Anleitung zur Selbstreflexion- Strategie neu denken- Unternehmenskultur als Ergebnis von KommunikationMit anschaulichen Grafiken und Skizzen für eigene Workshops - auch zum Download aufmyBook+.

Teil 1 Auf der Suche nach der agilen Organisation

1 Es war einmal der Kunde

Boris Gloger

Meine Frau ist Apothekerin. Sie liebt es, das letzte Quäntchen aus einer Tube herauszupressen, egal ob Zahnpasta, Senf oder Tomatenmark. Weil es Apotheker mit den Quäntchen sehr genau nehmen müssen, haben sie wohl auch dieses Gerät entwickelt, mit dem man wirklich den kleinsten Rest rausholen kann: Tube einlegen, drehen, Tube völlig leer. Einmal erzählte mir meine Frau von den strahlenden Augen einer älteren Dame, die mit einer fast aufgebrauchten Salbentube in die Apotheke gekommen war. Sie wollte sich eine neue holen, natürlich bekam sie die auch. Gleichzeitig bot meine Frau ihr aber auch an, die angebrochene Tube ganz auszuquetschen. Zehn Sekunden später war das erledigt und die Kundin war glücklich – jetzt reichte der Inhalt noch für zwei weitere Tage. Von diesem Wow-Erlebnis, wie es Autor Tom Peters nennen würde, erzählte die Dame ihren Freundinnen. Die Apotheke hat jetzt drei Stammkundinnen mehr.[15]

Eigentlich müsste ich Ihnen jetzt etwas über die unglaubliche Komplexität erzählen, in der sich Unternehmen heute zurechtfinden müssen. So fangen etwa 98 Prozent aller Artikel und Bücher an, wenn es um Change-Management und Organisationsentwicklung geht. Alles ist so wahnsinnig schnell und unübersichtlich geworden. Ja, natürlich ist es das. Aber es gibt eine Konstante: den Kunden. Sie wissen, diese Menschen, die Produkte kaufen. Aus den unterschiedlichsten Motiven, aber immer deswegen, weil ein Produkt einen persönlichen oder unternehmerischen Zweck besser erfüllt als alle anderen. Auch die Kunden haben sich verändert, selbstverständlich – aber das tun sie mittlerweile seit einigen Jahrtausenden. Klar, traditionelle Apotheken haben einen großen Vorteil: Sie sind nah an ihren Abnehmern. Meine Frau erlebt den Kunden täglich. Ihr Kunde ist meistens auch der Anwender. Sie kann sich innerhalb einer Sekunde eine Lösung, und sei sie noch so klein, überlegen oder ein Produkt anbieten, das bei einem bestimmten Problem hilft. In meiner Beratungswelt, in der Welt der Produktentwicklung im Softwarebereich, treffen meine Kollegen und ich bei großen wie kleinen Unternehmen genau das Gegenteil an. Wenn wir dort erklären, dass Scrum-Teams – also die Mitarbeiter, die das Produkt entwickeln – den Anwender kennen und sich mit ihm unterhalten können müssen, ernten wir interessante Reaktionen: vom bassen Erstaunen über amüsiertes Grinsen bis hin zu offener Ablehnung. Sofortige Zustimmung erleben wir selten. Wir haben auf etwas Unerhörtes hingewiesen: Darauf, dass Unternehmen Kunden haben. Mit Problemen, für die sie Lösungen suchen.[16]

Aus der Praxis

Wir sollten einem medizintechnischen Unternehmen dabei helfen, die Produktentwicklung mit Scrum zu beschleunigen und zu verbessern. Als ich mir die Mannschaft, die das Produkt entwickelte, anschaute, stellte ich fest: Die meisten hatten das Vorgängerprodukt noch nie im Einsatz in einem Labor gesehen. Sie sollten also ein Gerät entwickeln, von dem sie nicht einmal wussten, wie eine Medizinisch-technische Assistentin es bedient. Geschweige denn, in welchem Kontext dieses Gerät eingesetzt wird. Sicherlich kann man es ihnen erzählen, aber das ist etwas vollkommen anderes, als es selbst zu sehen. Wir erreichten, dass die Teams ein Labor besuchen konnten.

Was mein Team und ich statt der Hinwendung von Unternehmen zum Kunden erleben (und was man auch in den Wirtschaftsmedien zuhauf nachlesen kann), ist die ständige Beschäftigung mit sich selbst. Egal, ob wir mit unseren Seminarteilnehmern diskutieren oder mit den Menschen, denen wir in Veränderungsprojekten begegnen: Sie denken nicht darüber nach, wie sie ihre Kunden zufriedenstellen oder vielleicht sogar völlig happy machen können. In erster Linie geht es immer darum, den eigenen Arbeitsplatz zu sichern. Welche Veränderungen werden auf den Einzelnen zukommen und wie soll man in diesem neuen Rahmenwerk namens Scrum arbeiten? Erklären wir dann im Laufe des Tages, wie das agile Management-Framework Scrum tatsächlich funktioniert, werden die Gesichter immer länger und blasser. Denn allen wird klar: Um agil zu werden, muss man sich in erster Linie mit dem Draußen beschäftigen, also mit dem Kunden. Statt Nabelschau zu betreiben, muss der Blick nach außen gerichtet und der andere verstanden werden. Es gilt, die eigenen Arbeitsprozesse so zu verändern, dass sie einen Wert für den Kunden darstellen.[17]

Aber warum ist das so? Warum stellen sich Unternehmen so auf, dass sich ihre Mitarbeiter immer mehr von dem entfernen, was das Unternehmen einmal erfolgreich gemacht hat? Diese Frage stellen wir immer, wenn wir uns mit den CEOs oder Firmengründern treffen. Und immer bekommen wir die gleiche Antwort: Die Gründer kannten ihre Kunden, sie kannten den Markt, und sie wollten für diesen einen Kunden etwas erzeugen. Mit diesem Gedanken haben es viele Unternehmen an die Spitze gebracht und gleichzeitig ist auf dem Weg dorthin der ursprüngliche Gedanke verloren gegangen.

Worüber wir hier reden, ist nicht mit dem Servicemantra der 1990er-Jahre zu lösen, denn es geht um die Produktentwicklung. Mit unseren Beobachtungen sind wir nicht allein. Auch Reinhard Sprenger oder Stephen Denning kommen in ihren Büchern über „Radikales Management“ zu ähnlichen Befunden (Sprenger 2012, Denning 2010): Dank der Fixierung auf Kostensenkung und Shareholder-Value ist der Fokus auf den Kunden verschwunden. Trends zu setzen schaffen nur wenige, neue Arbeitsplätze zu schaffen noch viel weniger. Stattdessen wurde in den letzten zwei Jahrzehnten massenhaft Produktionswissen durch Offshoring ausgelagert, um nicht zu sagen: auf Nimmerwiedersehen verscherbelt.^1[18] Wo kein Wissen, da keine Innovation. Schon Peter Drucker schrieb in Management: „Because its purpose to create a customer, the business enterprise has two – and only these two – basic functions: marketing and innovation. Marketing and innovation produce results, all the rest are costs.“ (Drucker 1985, S. 57) Schon wieder geht es um den Kunden!

1.1 Wurzeln der Agilität

Das Gefährliche an Modewörtern ist, dass sie manchmal Tatsachen verschleiern. Meistens die Tatsache, dass es sich nicht um etwas grundlegend Neues handelt, sondern dass wir irgendwann – ebenfalls im Sog von Modeerscheinungen – von einem richtigen Weg und von unserem gesunden Menschenverstand abgekommen sind. Genau so verhält es sich mit der „Agilität“: Von der Software- über die Automobilindustrie bis zur Medizintechnik wollen Manager ihre Unternehmen heute agil machen. Wie bei vielen Trends der vergangenen Jahre beschäftigen sich viele Organisationen aber nicht mit den zugrunde liegenden Ideen. Viele wollen den schnellen Erfolg durch eine Methode, in unserem Fall Scrum, aber ohne die dazugehörigen Mühen. Wenn sich der Erfolg nicht einstellt, ist die Methode schuld – nicht der Umstand, dass man die dafür nötigen Veränderungen von Strukturen und Rahmenbedingungen nicht mit aller Konsequenz durchgeführt hat. Wenn eine agile Transition scheitert, dann meistens am mangelnden Glauben an die Sache und durch die Fehlannahme, dass sich erfolgreiche Veränderung an Terminpläne hält. Sie ist nicht einfach irgendwann beendet. „Agilität“ ist eine Haltung – und eine Haltung gibt man nicht nach Büroschluss ab.[19]

Aber zurück zu der Tatsache, dass Agilität nichts Neues ist. Kennen Sie Kelly Johnson? 1943, als Adolf Hitler seine Wunderwaffen entwickeln ließ, bekam der Konstrukteur von Lockheed Martin einen unmöglichen Auftrag: In 180 Tagen sollte er mit seiner Mannschaft einen völlig neuen Kampfjet bauen. Unmöglich? Kelly Johnson ist so vorgegangen: Er hat alle dafür notwendigen Ingenieure in ein Zelt gepackt, bürokratische Störungen ferngehalten, die Experten selbstorganisiert machen lassen und sie in Kontakt mit den Nutzern gebracht – mit den Piloten. Ergebnis: Die P-80, fertig entwickelt nach 143 Tagen und die Geburt von „Skunk Works“, der weitgehend autarken, bürokratiefreien Entwicklungsumgebung für radikale Innovationen bei Lockheed Martin.

Auch in der Softwareindustrie, von der die agile Welle angestoßen wurde, sind sogenannte agile Softwareentwicklungsmethoden im Grunde eine Wiederentdeckung. Ebenfalls ausgehend von der Rüstungsindustrie und den Erfahrungen des Mercury-Programms der NASA, in dem einige ihrer Softwareentwickler mitgearbeitet hatten, setzte die IBM Federal Systems Division lange Zeit auf iterative und inkrementelle Entwicklung (IID) (vgl. Larman, Basili 2003)[20]: Die Teams arbeiteten in sehr fokussierten, kurzen und zeitlich genau bemessenen Iterationen, also der wiederholten Anwendung des gleichen Prozesses. Daran schlossen sich Review-Phasen an und mit den erkannten Änderungsnotwendigkeiten ging es in die nächste Iteration. In einem internen Report an das IBM-Management schrieb M.M. Lehmann 1969 über die Vorteile von IID: „The basic approach recognizes the futility of separating design, evaluation, and documentation processes in software-system design. The design process is structured by an expanding model seeded by a formal definition of the system, which provides a first, executable, functional model. It is tested and further expanded through a sequence of models, that develop an increasing amount of function and an increasing amount of detail as to how that function is to be executed. Ultimately, the model becomes the system.“ (Larman, Basili 2003, S. 48) Das IID-Modell fiel gegen Ende der 1970er-Jahre einem neuen militärischen Standard der Softwareentwicklung zum Opfer, der das sequenziell ausgelegte Wasserfallmodell der Entwicklung favorisierte (aber belassen wir es aus historischer Sicht einmal dabei).

Eines sticht bei den zahlreichen „agilen“ Beispielen im Artikel von Larman und Basili besonders ins Auge: Es handelt sich keineswegs um triviale „Produkte“. Den Weltraum zu erobern oder einen Weltkrieg zu gewinnen, kann man wohl zur Gattung der komplexen Unterfangen zählen. Es waren Riesenprojekte, mit Hunderten involvierten Personen, und meistens hing von diesen Projekten das Leben von Menschen ab. Möglicherweise war die Welt damals wirklich einfacher, möglicherweise waren die Menschen noch nicht so verkopft wie heute. Jedenfalls gingen sie mit einem Prinzip ans Werk, das heute noch gültig ist, wenn man es mit komplexen Projekten zu tun bekommt und das auch grundlegend in der Arbeit mit Scrum ist:[21]

Zum Nachdenken

Fokussiere das Problem und dann zerlege es in kleine, überschaubare Einheiten. Arbeite eng mit dem Anwender zusammen und verbessere so Schritt für Schritt dein Produkt.

Versuche, der iterativ-inkrementellen Softwareentwicklung zu einem Comeback zu verhelfen, gab es immer wieder. Der wirkliche Durchbruch gelang aber erst Ende der 1990er-Jahre, als Software-Projekte so unübersichtlich geworden waren und die Entwickler unter einem solchen Leidensdruck standen, dass sie mit dem „Agile Manifesto“ lauthals „Stopp!“ schrien. 2001 trafen sich 17 Software-Entwickler – allesamt Koryphäen ihrer Zunft – und definierten ihren Zugang zu einer Form der Softwareentwicklung, in deren Zentrum die enge Zusammenarbeit zwischen Entwickler und Kunden steht.

„Manifest der agilen Softwareentwicklung

Wir zeigen bessere Wege auf, um Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.

Durch unsere Arbeit haben wir folgende Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge[22]

funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen

Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, messen wir den Dingen auf der linken Seite größeren Wert bei.

(www.agilemanifesto.org ; Übersetzung des Verfassers)“

Das Agile Manifesto fußt auf zwölf Prinzipien, die sich in den Rollen, Meetings und Artefakten von Scrum widerspiegeln und damit auch den Kern der agilen Organisation in sich tragen (www.agilemanifesto.org/principles.html):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.[23]
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

„Individuen und Interaktionen mehr als Prozesse und Werkzeuge“

Schauen Sie einmal auf Ihre eigene Projektpraxis: Wie oft erleben Sie, dass man nur einmal hätte miteinander reden müssen, um viele Wege abzukürzen, effektiver miteinander zu arbeiten und schneller ans Ziel zu kommen? Wie oft erleben Sie, dass die Ihnen zur Verfügung stehenden Prozesse Ihre Arbeit eher behindern als sie zu erleichtern?

Alle agilen Entwicklungsprozesse gehen davon aus, dass die Teammitglieder und alle anderen Stakeholder miteinander reden und sich ständig austauschen müssen, um ein wirklich gutes Produkt liefern zu können. Dabei ist es für die Selbstorganisation wesentlich, den Einzelnen zu respektieren und anzuerkennen, dass er sich von allen anderen unterscheidet. Es ist selbstverständlich, dass Teams mit klar definierten Prozessen und guten Entwicklungswerkzeugen ar...

Inhaltsverzeichnis

• Inhaltsverzeichnis
• Hinweis zum Urheberrecht
• Impressum
• Vorwort zur 2. Auflage
• Vorwort
• Eine kurze Wegbeschreibung
• Prolog
• Teil 1 Auf der Suche nach der agilen Organisation
• Teil 2 Scrum
• Teil 3 Die Umsetzung
• Literatur
• Über die Autoren
• Stichwortverzeichnis
• mybook