Analyse der Möglichkeiten für den Wissenstransfer von Business in die Scrum Teams

Inhaltsverzeichnis

1 Einleitung
1.1 Problemskizze
1.2 Ziele der Arbeit
1.2.1 Ziele
1.2.2 Einschränkungen
1.3 Aufbau der Arbeit
1.4 Lösungsskizze

2 Problemstellung
2.1 Kommunikation zwischen Business und Entwicklung
2.2 Benötigtes Fachwissen in Scrum Teams
2.3 Probleme der Wissensübermittlung

3 Grundlagen
3.1 Beschreibung von Scrum
3.1.1 Rollen
3.1.2 Artefakte
3.1.3 Ereignisse
3.2 Wissenstransfer
3.2.1 Kommunikation

4 Methoden für Wissenstransfer
4.1 Wissenstransfer aus Sicht von Scrum
4.1.1 Schwachstellen durch den Product Owner
4.1.2 Schwachstellen im Product Backlog
4.2 Integration von Methoden in Scrum
4.2.1 Klassische Methoden

5 Diskussion und Schlussfolgerung
5.1 Diskussion der Erkenntnisse
5.2 Schlussfolgerung
5.2.1 Reflexion

6 Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Darstellung, welches Event oder Artefakt für welchen Bereich verantwortlich ist. (z.B. Daily Scrum für Fortschritt) (Eigene Darstellung)

Abbildung 2: Ablauf von Scrum, Darstellung von CodeCentric, Solingen Germany (Schwaber, 2010, S. 15)

Abstract

In vielen Softwareentwicklungen wird nicht das entwickelt was sich der Kunde vorstellt. Dies geschieht meist aus dem Grund, dass sich die Entwicklung keine klaren Vorstellungen über die Anforderungen von der Fachabteilung machen kann. Der Mangel an Wissen wurde schon vor Jahren erkannt. Heute versuchen viele Unternehmen dieses Problem durch agile Methoden in den Griff zu bekommen. Die populärste agile Methode ist dabei das Scrum Framework. Die Stärken des Scrum liegen darin, alle Anforderungen an einem zentralen Ort, dem Product Backlog, abzulegen. Ebenfalls gibt es eine verantwortliche Person für das Produkt, den sogenannten Product Owner. Der Product Owner vereint mehrere klassische Rollen. Neben dem Management des Product Backlog, ist er für die Erstellung der Produktvision und der Road Map zuständig. Diese Zentralisierung des Produktewissens bringt viele Vorteile mit sich. Mit diesem Produktewissen beschäftigt sich diese Arbeit und versucht die Schwachstellen, die durch Scrum entstehen, darzulegen. Die grösste Stärke kann ebenfalls zur grössten Schwäche werden, da die Zentralisierung des Wissens in einer Liste und einer Person stattfindet. Es ist wichtig, dass der Product Owner nicht überlastet ist und auch die Befugnis hat, seine Rolle voll auszuüben. Ein typisches Problem das durch Überlastung entsteht, ist eine Verschlechterung des Product Backlogs, der entweder durch den Mangel an Kundenkontakt entsteht oder durch vernachlässigte Pflege des Product Backlog. Durch mangelnde Befugnis des Product Owners kann er seine Rolle nicht ausüben. Dadurch kann er die nötigen Entscheidungen nicht schnell genug treffen, was sich nachteilig für das Team auswirkt. Im Grunde muss man sagen, dass jegliche Abweichungen die ein Weglassen eines Scrum Bestandteils verursachen, sich negativ auswirken. Da es sich beim Scrum Framework um ein schlankes Vorgehensmodell handelt, welches nur die nötigsten Vorgaben macht.

1 Einleitung

Diese Arbeit beschäftigt sich damit, wie das Wissen über die Kunden von der Marketingabteilung sicher in die Software Entwicklung transferiert werden kann, unter der Verwendung des Vorgehensmodell Scrum.

1.1 Problemskizze

Im Grunde kennt jeder der eine Zeit lang in der Software Entwicklung gearbeitet hat, das Problem. Die gelieferte Software der Entwicklung erfüllt die Anforderungen, die zu Projektbeginn formuliert wurden. Trotzdem entspricht die erhaltene Software ganz und gar nicht den Vorstellungen des Kunden. Dies hat meistens zwei Gründe, der eine Grund liegt darin, dass die Anforderungen sehr generell beschrieben wurden und der Entwickler nicht genau wusste was er liefern soll. Der andere Grund liegt darin, dass die Gründe für gewisse Anforderungen der Entwicklung nicht klar sind. Eine oft gestellte Frage in der Entwicklung ist, warum der Kunde etwas möchte. Da diese Frage meist unbeantwortet bleibt, nimmt die Entwicklung für sie logische Antworten. Auf Grund dieser beiden Schwachpunkte implementiert die Entwicklung, was sie denkt das der Kunde möchte.

Diese beiden Gründe haben zur Folge, dass die gelieferte Software nicht dem gewünschten Resultat entspricht. Obschon beide Probleme auf der Seite der Anforderungen hier ihren Anfang nehmen, liegt die Ursache bereits etwas tiefer. Die Marketingabteilung spricht mit dem Kunden. Die Marketingabteilung wird anschliessend von der Abteilung der Anforderungsanalysten befragt, was der Künde wünscht. Darauf verpackt die Anforderungsanalysten die Wünsche des Kunden in einen Anforderungskatalog, welcher der Entwicklung vorgelegt wird. Auf den ersten Blick erscheint dieses Vorgehen, wie das Spiel bei dem ein Kind dem nächsten ein Wort in das Ohr flüstert und dann geht es in einer Reihe so weiter, bis am Schluss ein anderes Wort herauskommt.

Die Ursache ist das fehlende Wissen der Software Entwicklung über die Kundenwünsche. Obschon ein Informationsfluss besteht, entsteht in der Entwicklung nur ein geringes Wissen, über die Kundenwünsche. Dies soll durch das Vorgehensmodell Scrum verhindert werden. Nun stellt sich die zu erforschende Frage nach den Mitteln die Scrum bietet, wie auch nach den zu verbessernden Methoden.

1.2 Ziele der Arbeit

In den letzten Jahren hat in vielen Softwareentwicklungen Scrum Einzug gehalten. Es handelt sich um ein agiles Vorgehensmodell, welches viele Probleme von Anfang an verhindern soll. Aus diesem Grund wird Scrum so zugeschnitten, dass es sich mit einem Wasserfallmodel oder Hermes integrieren lässt.

1.2.1 Ziele

Das Ziel dieser Arbeit ist es zu untersuchen, welche Möglichkeiten Scrum dem Wissenstransfer von der Marketingabteilung zur Entwicklung bietet. Hierbei werden die in Scrum integrierten Mechanismen geprüft und analysiert. Zusätzlich wird versucht, gefundene Schwächen mit anderen Möglichkeiten aus dem Wissensmanagement zu decken.

1.2.2 Einschränkungen

In der Praxis gibt es viele angepasste Scrum Versionen. Solche Versionen versuchen Scrum in ein RUP – Vorgehensmodell einzubauen und das ganze noch mit einem V-Modell abzurunden. Natürlich kann es sein, dass es dafür regulatorische Gründe gibt, aber es handelt sich hierbei nicht mehr um Scrum. Wenn immer in dieser Arbeit von Scrum gesprochen wird, bezieht sich dies auf Scrum ohne Tailoring oder Integrationen in andere Vorgehensmodelle. Auch wenn es gewisse Tailorings gibt, die alle Regeln von Scrum beachten, werden diese in dieser Arbeit nicht behandelt.

Auch wird in dieser Arbeitauf die Art und Weise, wie neues Wissen in der Softwareentwicklung generiert wird verzichtet. Diese Arbeit legt den Fokus auf den Transfer von Wissen.

1.3 Aufbau der Arbeit

Im ersten Teil wird die Problemstellung der Arbeit beschrieben. Darin wird detailliert darauf eingegangen, worin die Schwierigkeiten in der Übermittlung des Wissens entstehen können. Anschliessend wird das Thema fokussiert, wie das Scrum Framework aufgebaut ist und was unter dem Term „Wissen“ in dieser Arbeit verstanden wird. Die Beschreibung von Scrum geht stark auf die einzelnen Artefakte ein, da diese Wissen in Form von Informationen speichern. Im dritten Teil werden Möglichkeiten beschrieben, wie das Wissensmanagement in Scrum gehandhabt wird oder wie man es sinnvoll ergänzen könnte. Die Schlussfolgerungen und Diskussion beschreiben die Schwächen oder mögliche Fehler die im Umgang mit Scrum gemacht werden.

1.4 Lösungsskizze

Um die Möglichkeiten für den Wissenstransfer zu analysieren, wird im ersten Schritt eine grosse Literaturrecherche durchgeführt. Die Beschreibungen von Scrum werden vor allem auf Quellen aufbauen, die von Jeff Sutterland oder Ken Schwaber sind. Diese zwei Herren sind die Begründer des Scrum Framework. Sie verbessern und entwickeln Scrum immer weiter. Durch die beschaffte Literatur wird sich ein Überblick über die Thematik gewährleistet. Nach dem Überblick werden die Möglichkeiten von Scrum aufgeführt und analysiert. Die dadurch erkannten Schwächen und Stärken werden dann anschliessend im letzten Kapitel behandelt.

2 Problemstellung

Im folgenden Kapitel wird detailliert auf die zu analysierenden Problemstellungen dieser Arbeit eingegangen, wobei als erstes die Ursache beschrieben wird. Diese liegt in der Kommunikation zwischen dem Business und der Softwareentwicklung. Da hier das Wissen von den Kundenwünschen in die Entwicklung übertragen werden soll. Anschliessend wird darauf eingegangen, wie viel Wissen überhaupt für die Erfüllung der Aufgaben ins Team übertragen werden muss. Diese Übertragung von Wissen besitzt immer gewisse Probleme, auf welche am Ende dieses Kapitels eingegangen wird.

2.1 Kommunikation zwischen Business und Entwicklung

Die Kommunikation zwischen dem Buisness oder Fachbereich mit der Softwareentwicklung, ist meistens eine indirekte Kommunikation. Diese läuft meist über die Anforderungen, die am Anfang erfasst werden. In dem klassischen Vorgehen werden zuerst Anforderungen gesammelt. Darin sollen alle Wünsche des Kunden beschrieben werden. Diese Anforderungen werden, sobald man alle nötigen Bedürfnisse und Erwartungen geklärt hat, einbezogen. Anschliessend wird der Inhalt analysiert und ein Umfang festgelegt. Die Festlegung des Umfangs wird mit dem Fachbereich durchgeführt. Anschliessend wird der Projektstrukturplan festgelegt. (Project Management Institute Inc., 2008, S. 49 ff.) Daraufhin wird nach diesem Projektstrukturplan gearbeitet und die Anforderungen werden so umgesetzt wie sie am Anfang festgelegt wurden. Jede Änderung sollte während dem Projekt festgehalten werden, was in den meisten Projekten mit einem Change Management geregelt wird.

In Scrum gibt es keinen fixierten Anforderungskatalog. Es besteht zwar einen Anforderungskatalog, aber dieser kann von dem Produkteigentümer, wie auch von der Softwareentwicklung verändert werden. Nach jeder Iteration treffen sich Produkteigentümer und Softwareentwicklung, begutachten das momentane Produkt und modifizieren gegeben falls den Anforderungskatalog. Da die Stakeholder direkt im Projekt mitarbeiten, ist das gesamte Wissen vor Ort verfügbar. Die komplette Anforderungsaufnahme und die Dokumentation der Anforderungen obliegen den Produkteigentümern. In komplexen Projekten existiert meist mehr als ein Produkteigentümer. Jedoch sollte es strickt nach Scrum nur einen Produkteigentümer geben. (Pichler, 2012, S. 184) Dieser Produkteigentümer sollte die Vision des Produktes in das Team tragen. Sein Arbeitsbereich umfasst die Aufgaben der klassischen Rollen, des fachlichen Anforderungssteller, Verantwortlicher für den Betrieb des Systems, Unternehmensarchitekt, Prozessverantwortlicher und des professionellen Anforderungsanalysten. (Scrum Kompakt) In Scrum übernimmt im Grunde der Produkteigentümer, der Product Owner, den gesamten Transfer des Wissens.

[...]