Regel drei: Projektmanager müssen wissen, was Entwickler tun
Ein weiterer weit verbreiteter Mythos, dem ich in meiner täglichen Arbeit begegne, ist, dass Agilität einfach jeder sofort können müsse. Es heißt, wir nennen es Scrum, arbeiten in Sprints, klicken ein paar grob definierte Tickets für die Entwickler zusammen und schon sind alle agil.
Das kann nicht funktionieren. In meiner wissenschaftlichen Ausarbeitung mit dem Titel Agile-Emotional-Leadership - Erfolgsfaktoren zum Führen in agilen Projekten wird deutlich, dass neben dem Wunsch, dem Willen und dem Wortschatzwissen vor allem fachliches Wissen Voraussetzung für eine erfolgreiche agile Transformation ist.
Ein gutes Beispiel hierfür ist die Definition einer Aufgabe für einen Entwickler. Ich möchte meiner eigenen Gattung der Projektmanager natürlich keine grundsätzliche Unfähigkeit unterstellen, erlebe aber immer wieder zum Beispiel Product Owner oder Projektmanager (je nachdem, wie sie im Unternehmen genannt werden), die überhaupt kein Wissen über die Tätigkeiten eines Entwicklers haben. Die richtige Einschätzung "Ich bin kein Entwickler" bedeutet nicht, dass man die Verfahren und Vorgehensweisen nicht kennen sollte.
Als Autofahrer sollte man zum Beispiel wissen, wie eine Bremse bedient wird, auch wenn man sie nicht herstellt. Zu wissen, was ein Entwickler tut, heißt nicht, dass man für die Definition einer Aufgabe den Entwickler zu sich zitiert, um dann mit ihm gemeinsam die Arbeit zu machen. Die Person, die eine Aufgabe definiert, sollte aber zum Beispiel wissen, wie man eine typische User Story schreibt. Eine User Story ist eine Anforderung an eine Softwareanwendung, die nahezu in Alltagssprache verfasst ist und selten länger als fünf Sätze ist. Es hilft Entwicklern ungemein, wenn Screenshots oder Zeichnungen solche User Storys illustrieren und diese dadurch besser visualisiert werden.
Einige Kollegen benutzen für Design-Dummys gerne Tools wie Anima App und bauen Prototypen, auf deren Grundlage die Entwickler Storys besser verstehen können. Umgekehrt sind Entwickler hilfreich, die ein grobes Kosten-Nutzen-Verständnis haben. Verantwortlich dafür ist zwar der Projektmanager/Product Owner. Wenn man gemeinsam Lösungen erarbeitet, sollte ein Entwickler diese Thematik jedoch schon einmal gehört und verinnerlicht haben. So vermeidet man Ansätze, die von Beginn an unrealistisch sind, weil sie zu teuer werden.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Regel zwei: Vorgesetzte sind auch beim agilen Arbeiten wichtig | Regel vier: Es braucht Zeit. Es braucht Fehler. Es ist nie zu Ende. |
Das funktioniert in der Entwicklung von Webanwendungen, wo SCRUM bekanntlich herkommt...
Manager können gar keine guten Kundenbeziehungen machen. Der Kontakt mit dem Kunden...
Wie Du selbst schreibt: "hat sich schon einiges (...) und der Kultur geändert" Ja die...
Sehe oft das Problem im SCRUM Teams dass es heisst "das Team organisiert sich selbst...
Hallo Maconry, Danke für den Kommentar zum Artikel. Im speziellen Fall war es eine Lösung...