Im letzten Artikel ging es um die Herausforderungen im Projektmanagement, wenn man mit festen Mitarbeitern arbeitet. Darin habe ich bereits angekündigt der SCRUM Methode eine Chance zu geben. Diese habe ich mir mit meinem Team nun etwas genauer angesehen und die ersten Schritte eingeleitet. In Bezug auf die praktische Umsetzung in kleinen Unternehmen erscheint uns die Methode an einigen Stellen jedoch nicht ausgereift. Um diese Punkte und ihre Lösungsansätze geht es im folgenden Artikel.
Scrum allgemein
Da sich die Unzulänglichkeiten von Scrum aus seiner Entstehung ergeben, hier eine kleine Einführung. Scrum kommt aus der Softwareentwicklung. In der Methode geht es um die Planung von Funktionen und deren Umsetzung in kleinen, zeitlich auf wenige Wochen begrenzten Projekten (sog. Sprints). Die Teams erhalten vom Product Owner Vorgaben zu einem Feature oder Ziel, das meist aus Sicht der Nutzer beschrieben wird. Die technische Umsetzung obliegt dann dem Team, in dem alle Kompetenzen versammelt sein sollten. Hinzu kommt ein Scrum-Master, der den Scrum-Prozess überwacht, jedoch inhaltlich keinen Einfluss hat. Zur Methode gehören ein initiales Treffen zur Übergabe der Anforderungen und Definition der notwendigen Aufgaben (Sprint-Meeting), das tägliche Kurzmeetings über den Stand (Daily Scrum) und je ein Treffen für die Übergabe der Ergebnisse und Auswertung des Prozesses aus Sicht des Projektmanagement.
Scrum im kleinen Team?
Wir haben in den letzten Wochen festgestellt, dass uns spontane Aufgaben und Ideen zunehmend bei der Arbeit hemmen. Neue Ideen sind grundsätzlich wichtig, aber zu häufig haben wir den Fokus verloren. Scrum als Methode soll uns nun dabei helfen uns wieder auf Kernaufgaben zu fokussieren. Bereits bei der Vorbereitung der ersten Sprints haben wir gemerkt, dass wir Projekte und ihre Hintergründe viel genauer definieren müssen, was auch mal dazu führt, dass sich die Ziele eines Projektes als weniger wichtig herausstellen als andere. Allein diese Evaluation soll mit wachsender Übung mehr Zeit sparen, als die Methode an sich benötigt.
Einschränkungen bei Scrum in kleinen Unternehmen
Zu wenige Mitarbeiter
Die Herausforderung bei der Einführung von Scrum sehe ich größtenteils in der Art des Teams. Während Scrum für größere Teams entstand, in denen ausreichend Personen vorhanden sind um neben den Fachleuten zur Umsetzung einen zusätzlichen Product Owner und einen Scrum Master zu besetzen, sind bei uns grundsätzlich nicht mehr als 3-4 Personen verfügbar. Auch allein wegen der zur Umsetzung notwendigen Kompetenzen ist eine Trennung zwischen Product Owner, Scrum Master und Teammitglied nicht immer möglich.
Meta-Meetings
In großen Organisationen erscheint es durchaus sinnvoll und möglich, dass ein Product Owner als Gate Keeper für das nächste Feature fungiert. Bei uns ist es jedoch angebrachter, dass die wenigen im Team gemeinsam diese Rolle erfüllen. Das schafft mit einer Art Meta-Meeting eine weitere Instanz, die aber notwendig ist.
Parallele Sprints
Eine Frage, die ich anhand der Fachliteratur noch nicht geklärt habe ist, was mit Leuten passiert, die nicht in einem aktuellen Sprint arbeiten. Manche unserer potentiellen Sprints haben es zudem an sich, dass sie allein kein Vollzeitprojekt sind. Also entstehen parallele Sprints. Diese so miteinander zu koordinieren sehe ich als Aufgabe des Meta-Meetings.
Laufende Aufgaben
Mit der Einführung von Scrum erhoffe ich mir, die Flut an neuen Ideen und Aufgaben zu bändigen. Doch die Methode scheint mir nicht für jenen Teil geeignet zu sein, der mit laufenden Aufgaben zu tun hat. Das sind administrative Sachen, die Leitung der Redaktion, Suchmaschinenoptimierung und natürlich Kommunikation. Wir haben für die Aufwandsabschätzung zunächst „festgelegt“, dass wir maximal 50% unserer Zeit für Sprints einplanen und der Rest sowieso in laufenden Arbeiten drauf geht.
Scrum-Aufwand
Schon zu Beginn haben wir gemerkt, dass Scrum sehr zeitintensiv ist. Neben der durch Scrum ja zeitlich begrenzten Daily-Scrums und Sprint-Meetings betrifft das auch die Arbeit der Product Owner. Wenn diese „richtig“ gemacht werden soll, dann gilt es auch diese Zeit einzuplanen. Wir sind dann darauf gekommen, das Vorbereiten eines Products als eigenen Sprint durchzuführen, weil auch hier zur Informationsgewinnung mehr als nur eine Person erforderlich ist. Im Meta-Meeting legen wir zudem zunächst 2-3 potentielle Products fest, statt mal so nebenbei alle Ideen zu Products auszuarbeiten.
Kaum haben wir uns für Scrum entschieden, da bauen wir schon wieder daran rum. Dennoch fühlt sich die Entscheidung noch sehr gut an und hat sogar (emotional) zur Arbeitsentlastung beigetragen. Ich werde auf gruenderstory.de weiterhin über die Umsetzung und unsere Erfahrungen mit Scrum berichten, freue mich aber auch über eure Kommentare und Fragen zu diesem Thema.
„Kaum haben wir uns für Scrum entschieden, da bauen wir schon wieder daran rum.“ Scrum ist ein Framework, da kann man sich schon die Sachen die nützlich sind, herausnehmen und Dinge die man nicht braucht, getrost ignorieren. Ich würde es also nicht als herumbauen sehen sondern einfach als Entwicklung der eigenen auf Scrum basierenden Lösung 🙂
Hi Chris,
vollkommen richtig. Ist nur gut, zu Beginn mehr Orientierung zu haben. Gerade was die Rollenverteilung angeht haben wir erst langsam eine Idee davon, wo z.B. der Scrum-Master anfängt oder der Product-Owner aufhört. Naja, langsam kriegen wir den Dreh ja raus 🙂
VG
Thomas
Das die Tätigkeit des POs zeitintensiv ist sollte Sie nicht verwundern: der ist schließlich der Verantwortliche für die Anforderungserhebung. Und das ist nun mal keine triviale Aufgabe, auch wenn man in agilen Ansätzen auf eher leichtgewichtige Methoden wie User Stories setzt anstatt auf (vermeintlich) vollständig ausgearbeitete Pflichtenhefte à la Wasserfall. Oder haben Sie vorher einfach ad hoc angefangen runter zu implementieren?
Ich habe selbst auch schon mal in einem Team von 5 Personen die Erfahrung gemacht was passiert, wenn alle Entwickler gleichzeitig auch noch PO sind: unsere Lösung bestand darin das Backlog Grooming und die Sprintplanung zu einer Monstersitzung zusammen zu legen. Allerdings halte ich das gleichermaßen für eine Verlegenheitslösung.
Bezüglich der Rollen: man kann Entwickler und entweder Scrum Master oder PO in Person vereinigen. Aber Scrum Master und PO geht meiner Meinung nach nur wenn man eine gespaltene Persönlichkeit hat.
Bezüglich parallelen Sprints: finde die Idee interessant, aber würde vom Bauchgefühl eher dazu tendieren für Miniprojekte die Iterationen zu verkürzen (warum sollte eine Sprint gleich eine oder gar zwei volle Arbeitswochen umfassen, wenn der Projektscope absehbar sehr klein ist?).
Ich denke Prozessmodelle habe Grenzen innerhalb derer sie gut skalieren, und mit 3-4 Personen dürfe wohl die untere Schranke für Scrum gut markiert sein.
Hallo Fabian,
wir nehmen die Aufgabe des PO schon ernst, haben aber jetzt bei den ersten Sprints gleich das Problem gehabt, dass einige Aspekte nicht vom PO vorausgesehen werden konnten, was eine Folge an Sprints nach sich zog.
Wir sind nur für die Priorisierung alle in der Rolle der Product Owner. Sobald wir uns bewusst sind, was die nächsten vorzubereitenden Products sind, wird ein konkreter PO ernannt und bleibt es auch.
Parallele Sprints sind daher notwendig, weil sich gewisse Teile aus div. externen Gründen nicht schneller umsetzen lassen oder Teammitglieder mit unterschiedl. Fähigkeiten unterschiedl. stark eingebunden sind.
Ich stimme auf jeden Fall zu, dass Scrum nicht pauschal in kleinen Teams funktioniert. Wir picken uns daher einzelne Elemente raus, die sinnvoll sind, wie etwa Product Owner, Scrum Master und regelmäßige Meetings.