Schulung: Scrum - Agiles Projektmanagement
Am 15.06.2007 fand in unseren Räumen in Zusammenarbeit mit Boris Gloger von SPRiNT-iT eine Einführung in agiles Projektmanagement mit Scrum statt, die ich hier noch einmal kurz zusammenfassen möchte.
Wir würden uns freuen, wenn die Teilnehmer des Seminars:
- ganz unten am Ende der Seite per Kommentar Ihre Meinung zu der Veranstaltung abgeben würden (diese sind dann öffentlich sichtbar)
- zusätzlich unser Formular Veranstaltungsbewertung ausfüllen (Veranstaltungsnummer: 1423), damit auch wir uns kontinuierlich verbessern können. Das Formular ist kurz und anonym.
Bereits am Abend vorher hatten die Teilnehmer Gelegenheit, sich beim GFWM-Stammtisch Mittelfranken auf das Thema einzustimmen. "Scrum" - der Begriff benennt im Rugby das "Gedränge" (aus de.wikipedia.org): "Ein Gedränge' (engl. scrum) wird gebildet, wenn sich ein oder mehrere Spieler beider Mannschaften gegenüber, auf den Füßen stehend, in körperlichem Kontakt um den auf dem Boden liegenden Ball zusammengeschlossen haben und versuchen, den Gegner wegzuschieben. ..."
Nonaka und Takeuchi befanden 1986, dass das, was sie bei der Produktentwicklung in Organisationen wie Honda, Xerox, Yamaha etc. beobachteten (s. HBR 1986: "The New New Product Development Game", pdf), im Kern dieser Rugby-Methode ähnelte: Ein Projektteam kümmert sich abgeschlossen vom Rest der Welt ausschließlich und ohne organisatorische Einschränkung darum, ein neues Produkt zu entwickeln und zwar vor dem Wettbewerber.
Ken Schwaber und Jeff Sutherland nutzten die Beobachtungen von Nonaka und Takeuchi für die Software-Entwicklung, entwickelten eine entsprechende Vorgehensweise und gaben ihr den Namen "Scrum".
Scrum ist inzwischen besonders in der amerikanischen Software-Welt, aber auch im Osten und Norden Europas, eine gern genutzte Methode, Software agil zu entwickeln.
In Deutschland hält Scrum nur langsam Einzug. Die Gründe sieht Boris Gloger in folgenden Punkten: Zum Einen ist vieles aus Scrum in Deutschland ohnehin üblich, so dass bei einem oberflächlichlichen Blick auf Scrum mancher Projektleiter denken mag: "Na, das machen wir doch eh schon. Dafür brauchen wir kein Scrum." Zum Anderen ruft Scrum mit seiner Eigenart, Schwachstellen und Probleme innerhalb kürzester Zeit sichtbar zu machen, Widerstand bei den Führungspersonen hervor, die bislang ihre Projektreports gern mit der Formulierung "alles bestens" eröffnet und beendet haben. Eine weitere Schwierigkeit haben Organisationen, deren Herz ihr Ogranigramm ist und die als Aufbauorganisation die Zusammenarbeit zwischen OEs in Form von querfunktionalen Teams nicht zulassen.
Dabei sieht das Scrum-Rezept vergleichsweise einfach aus:
- 1 Vision
- 1 Product Owner
- 1 Scrum Master
- 1 Team (5-7 Mitglieder, alle notwendigen Funktionen vertreten)
- 1 Product Backlog
- 1 Selected Product Backlog je Sprint
- 1 Sprint Backlog je Sprint
- 1 Impediment Backlog
- Meetings (Daily Scrum, Estimation Meeting, Retrospective, Sprint Planning 1+2, Sprint Review Meeting)
Diese Zutaten zusammen mit ein paar einfachen Regeln basierend auf dem Deming-Cycle (Plan-Do-Check-Act) ergibt Scrum. Anders als bei den meisten anderen Projektmanagement-Methoden ist es bei Scrum so: Zutaten und Regeln sind einfach, das Starten leicht gemacht, das konsequente Leben ersteinmal schwierig - aber immerhin, man beginnt mit der Umsetzung. Bei anderen Methoden ist das Regelwerk so kompliziert, dass man garnicht erst anfangen kann.
Kommunikation und Vertrauen als Backbone
Die Anzahl der Meeting-Typen gibt einen Hinweis darauf, was Scrum unter anderem ausmacht: Scrum ist ein fortwährender Dialogprozess, je nach Zeitpunkt sind unterschiedliche Personen(-gruppen) beteiligt, immer aber sind es alle, die für den entsprechenden Schritt notwendig sind. Das Daily Scrum z.B. findet täglich (!) statt und erfordert die Anwesenheit aller (!) Team-Mitglieder, unabhängig davon, zu welcher OE sie gehören. (Be-)ständige, regelmäßige, offene Kommunikation, bei der der Projektfortschritt und vorallem auch die Hindernisse offen angesprochen werden, sind der Kern von Scrum.
Ein Scrum-Team arbeitet selbstorganisiert. Vorgabe ist die Vision des Product Owners, der diese aus den Gesprächen mit dem Kunden (dessen Vision) entwickelt hat und die sich in dem Product Backlog manifestiert. Das Product Backlog ist die priorisierte Liste der Features, die das Team entwickeln soll. Eine Version davon, die das Team sich im Spriont Planning 1 erarbeitet und die einen Arbeitsumfang von ca. 30 Tagen (Sprint) beinhaltet, bildet das Selected Product Backlog. Im Sprint Planning 2 wird entschieden, welche Arbeiten notwendig sind, um das Selected Product Backlog abzuarbeiten (Sprint Backlog). Das Team entscheidet selbst, wer sich um welche Aufgabe kümmert. Die Aufgaben werden dabei so getaylort, dass sie nicht länger als 8 Stunden dauern. Ob die Aufgaben erledigt wurden und was das Team möglicherweise an der Abarbeitung hindert wird beim Daily Scrum besprochen. Die Aufgabe des Scrum Masters, der die Hindernisse in sein Impediment Backlog einträgt, ist es, den Prozess am Laufen zu halten, das Team vor störenden Einflüssen zu schützen und etwaige auftretende Schwierigkeiten aus dem Weg zu räumen. Nach jedem Sprint wird im Sprint Review das Produkt (die neuen Features etc.) vorgestellt und in einer Retrospektive Verbesserungspotenzial identifiziert und im nächsten Sprint umgesetzt (je nach Zuständigkeit durch das Team oder den Scrum Master). Ein Burn-Down-Chart zeigt täglich den Projektstand.
Nach erstaunlich kurzer Zeit, also bereits nach den ersten 30 Tagen hat der Kunde etwas in der Hand, das funktioniert und das ihm zeigt, ob das Projektteam in die gedachte Richtung arbeitet. Dank der kurzen Zyklen und der hohen Transparenz (der Kunde darf bei den Reviews dabei sein) werden Anforderungen des Kunden regelmäßig mit den Ergebnissen abgeglichen, so dass es am Ende des Projekts, so es überhaupt ein Produkt gibt, nicht zu einem bösen Erwachen kommt.
Wie wichtig der fortwährende Dialog und die Einbeziehung aller Stakeholder (besonders auch des Kunden ist) illustriert Boris Gloger an einer kleinen Geschichte von einem Mann, der sich seine Traumtorte wünscht. Mit einer anfänglich schwammigen Vorstellung vom perfekten Kuchen wendet sich der Mann an einen Bäcker, dernach guter Scrummanier den Mann in sämtliche Prozessschritte einbezieht und ihm immer wieder auch das momentane Ergebnis zeigt. Im Diallog und über die Zeit verändert sich das Bild des perfekten Kuchens und am Schluss hält der Mann den für ihn perfekten Kuchen in Händen, der allerdings hat mit der ursprünglichen Vorstellung des Mannes nichts mehr gemein. Ein Phänomen, das besonders in der Software-Entwicklung mehr als bekannt ist.
Scrum und Wissensmanagement
Und was hat das mit Wissensmanagement zu tun? - Die Tatsache, dass ausgerechnet Nonaka und Takeuchi, die aus der Geschichte des Wissensmanagement nicht weg zu denken sind, die wesentlichen Merkmale von Scrum als erste beschrieben haben, ist nicht der einzige Grund, warum auch wir im Wissensmanagement uns mit Scrum auseinandersetzen sollten: Im Wissensmanagement haben wir verstanden, dass das Wissen der Mitarbeiter die wichtigste Ressource einer Organisation ist. Dieses Wissen gilt es zu pflegen und beständig weiterzuentwickeln, um die Organisation in eine lernende Organisation zu transformieren.
"A learning organisation is an organisation skilled at creating, acquiring and transferring knowledge, and modifying its behaviour to reflect new knowledge and insights." (Garwin, 1993)
Eine Organisation jedoch kann nicht lernen. Das können nur die Menschen, die dort arbeiten. Und das führt uns zu Scrum.
Lernen aus Projekten
Scrum basiert darauf, dass die Projektmitarbeiter täglich Erfahrungen austauschen. Dadurch, dass Scrum-Teams aus Mitarbeitern verschiedener OEs, Funktionen und Hierarchiestufen bestehen, ist das Lernen auf individueller Ebene und über OEs und Funktionen wenigstens für die Beteiligten gesichert. Dadurch ist Scrum ein wesentliches Puzzleteil auf dem Weg zum ganzen Bild der lernenden Organisation. Was Scrum nach Schwaber und Sutherland nicht (explizit) leistet, ist das Übertragen der Erfahrungen aus einem Projekt in andere Projekte und auf die ganze Organisation. Doch in der Wiege von Scrum, jenem HBR-Artikel von Nonaka und Takeuchi, wird eine interessante Beobachtung das organisationale Lernen betreffend gemacht:
"The drive to accumulate knowledge across levels and functions is only one aspect of learning. We observed an equally strong drive on the part of the project members to transfer their learning to others outside the group."
Dieses Phänomen ist leicht zu erklären: Scrum-Projekte sind erfolgreich und machen Spaß. Scrum-Projektmitarbeiter schwärmen von ihren Projekten, sie erzählen ihre Geschichte, und Geschichten-Erzählen (Storytelling) ist eine der ältesten und besten Wege aus Erfahrungen zu lernen. Andere Wege des organisationalen Lernens die Nonaka und Takeuchi beobachteten:
- "Osmosis": Projektmitarbeiter werden nach Ende des Projekts auf neue Projekte verteilt und bringen dort ihr Wissen ein.
- "Standard practice": Bewährte Projektvorgehensweisen werden als Standardvorgehensweise übernommen.
- "Institutionalization": Erfahrungen aus erfolgreichen Projekten verändern Wege des Denkens und Kultur einer Organisation.
Meiner Ansicht nach ist die in Scrum geforderte Zusammensetzung der Teams eine hervorragende Möglichkeit, Erfahrungen durch die Organisation sickern zu lassen. Ein breites Lernen ist nur möglich, wenn die Teams immer wieder neu zusammengestellt werden. Die Erfahrung zeigt jedoch, dass die Teams am besten arbeiten, die bereits mehrere Projekte gemeinsam gemeistert haben. Eine weiteres Risiko besteht darin, dass diese Vorgehensweise auch eine gewisse Abhängigkeit vom glücklichen Zufall bedeutet: Tritt ein Problem auf, das ein anderes Team bereits gelöst hat, und ist nicht zufällig ein Mitglied des früheren Projekts beteiligt, muss das Problem neu gelöst werden. - Es sei denn, eine Organisation sammelt die Erfahrungen aus früheren Projekten (z.B. in Lessons Learned Systemen) und schafft es, diese für alle Mitarbeiter präsent und leicht zugreifbar zu halten - zusammen mit den jeweiligen Erfahrungsträgern.
Das nämlich müssen wir verstanden haben: Die Menschen sind es, die das Wissen der Organisation ausmachen und ihr Erfolg ermöglichen.
Workshop "Wissensorientiertes Projektmanagement"
Wer sich intensiver mit dem Thema "Wissensorientiertes Projektmanagement", also mit dem Lernen in und aus Projekten, beschäftigen möchte, ist herzlich eingeladen, an unserem nächsten COGNEON Knowledge Jam am 12.07.2007 teilzunehmen. Wir wollen bei diesem eintägigen Workshop Erfahrungen darüber austauschen, wie wir vorhandenes Wissen in Projekte hineinbringen, entstandenes Wissen laufend für alle verfügbar machen und aufgrund der Erfahrungen in den Projekten Verbesserungen anstoßen können. Die Teilnehmer kommen aus unterschiedlichen Branchen (Automobil, Software-Entwicklung, Stahl, angewandte Forschung etc.) und Funktionen, so dass wir auf einen vielseitigen Erfahrungsschatz zugreifen können.
Mitglieder der Gesellschaft für Wissensmanagement e.V. sowie Mitglieder der Deutschen Gesellschaft für Projektmanagement e.V. erhalten einen Rabatt von € 50,- auf den Teilnahmebetrag. Bei aktuellen Kunden der Cogneon GmbH sind 2 Teilnehmer kostenlos.
- Weblog von kerstin.buecher
- Neuen Kommentar schreiben
- 1137 Aufrufe