Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
Einer meiner Leser der ersten Stunde hat mich neulich auf einen interessanten Blogbeitrag zum Thema Scrum hingewiesen, der auf dem PM-Blog unter dem Titel → ScrumBut – “We use Scrum, but…” zu lesen ist. Wie Sie wissen, arbeiten heute viele Unternehmen im IT Sektor nach der SCRUM Methode, d.h. einem Ansatz, der sich den Zielen Lean (Einfachheit) und Agile (Agilität) verschrieben hat. Der erwähnte Artikel befasst sich mit der Umsetzung dieser Methode.
Vielen dieser Unternehmen fällt es schwer, den SCRUM-Ansatz 1:1 umzusetzen. Da in diesen Unternehmen die SCRUM Methode mit Änderungen verwendet wird, wurde der Begriff ScrumBut geprägt, den dieser Blogautor und ich heute verwenden. In der Langversion, und übersetzt bedeutet dieser Begriff Wir benutzen Scrum, aber…
Wie Sie in dem erwähnten Blogbeitrag nachvollziehen können, kommen in vielen Firmen Abwandlungen zum Einsatz. Auf der anderen Seite sieht aber auch niemand (zumindest niemand, der vom PM-Blog zitiert wird) darin ein Problem. So kommt der Autor, Stefan Hagen, selbst zu dem folgenden Fazit:
FAZIT: Ich denke, ScrumBut ist in den meisten Fällen sinnvoll und notwendig. Allerdings sollte man es sich in der Praxis nicht zu leicht machen. Denn das “Herz” von Scrum – so wie es auch im agilen Manifest beschrieben ist – sollte niemals verloren gehen.
Ach ich arbeite nun schon einige Zeit in einem Scrum-Team, und habe so einige Erfahrungen mit diesem Ansatz gesammelt. Generell halte auch ich es nicht für ein Problem, die Methode abzuwandeln, so dies einen Sinn macht, und den eigentlichen Ansatz nicht ad-absurdum führt. Im Gegenteil, manchmal sind diese Abwandlungen notwendig. Man könnte viel darüber schreiben. Ich will mich auf drei Aspekte beschränken.
Einen Punkt, der sicher häufiger zu Abwandlungen führt, kann man direkt in der Grafik sehen, die in dem Blogbeitrag gezeigt wird (siehe → Grafik). Die SCRUM Methode geht generell davon aus, daß die Qualifikationen der einzelnen Team Mitglieder austauschbar sind, und, daß ein Backlog existiert, der von jedem Teammitglied bearbeitet werden kann.
Dies ist meiner Erfahrung nach nur in bestimmten Teams der Fall, nämlich dann, wenn ein Team neue Produkte auf der Grundlage einer einheitlichen Technologie entwickelt. Wenn sich ein Team demgegenüber aber eher mit der Weiterentwicklung bestehender Funktionalitäten auseinandersetzen, kommen Spezialisierungen ins Spiel, die dafür sorgen, daß eben nicht mehr jeder Alles machen kann.
Ein ähnlicher Effekt tritt in Bezug auf die einzelnen Wissensgebiete ein, die an einem Produkt mitwirken. So geht die Scrum Methode davon aus, ein homogenes Entwicklerteam zu haben, das relativ autark agieren kann. In der Realität besteht eine Entwicklung aber oft aus unterschiedlichen Teilen, wie dem Coding, der Dokumentation, oder den Qualitätssicherungsmaßnahmen, und sie bettet sich in einen größeren Rahmen ein. Bereits hier macht es nicht immer Sinn, jeden Alles machen zu lassen.
Meiner Erfahrung nach fällt es zum Beispiel vielen Softwareentwicklern schwer, eine Dokumentation zu verfassen, die verständlich ist. Für diese Aufgaben werden dann gerne spezialisierte Dokumentationsentwickler eingesetzt. In anderen Fällen, muß zum Beispiel dafür gesorgt werden, daß sich die Qualitätsstrategie in einen übergreifenden Rahmen einordnet. Auch die überträgt man gerne Spezialisten, alleine schon aus Know-How Gründen.
Speziell bei Dokumentationsentwicklern, oder Qualitätsingenieuren kommt dann noch eine weitere Spezialität zum Tragen: Beide Bereiche müssen oft gruppenübergreifend koordiniert werden, um Doppelarbeiten zu vermeiden – jedenfalls in stärkerem Umfang, als dies beim Coding der Fall ist. Damit kommt es aber auch zu Abhängigkeiten zwischen Teams, die im ursprünglichen Modell nicht angedacht sind.
Die ursprüngliche Methode geht davon aus, daß sich der Produktbacklog soweit zerteilen läßt, daß sich die einzelnen Aufgaben in einem Sprint erledigen lassen. In der Realität findet man jedoch häufig Langläufer vor, die über mehrere Sprints entwickelt werden müssen. Diese Langläufer führen zu Verkettungen zwischen einzelnen Sprints, und sie machen es notwendig, Mittel und Wege zu finden mit solchen Anforderungen sinnvoll umzugehen. In der Praxis unterteilt man daher gerne einzelne Entwicklungen in Blöcke, die nach einem Miniwasserfall abgewickelt werden.
In den folgenden Artikeln finden Sie weiterführende Informationen zum heutigen Thema:
Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
