Agile Schätzverfahren im Vergleich zu traditionellen Methoden

KLASSISCHE SCHÄTZMETHODE

Eine Aufwandsschätzung ist wichtiger Bestandteil im Planungsvorgang eines Projektes. Klassisch wird dabei die Spezifikation des Ergebniszieles im Projektvorhaben (zB in Form eines Lastenheftes) analysiert und den Anforderungen eine Anzahl konkreter Durchführzeiten und -kosten gegenübergestellt.

ABSTRAKTE SCHÄTZMETHODE

Ein wichtiger Unterschied zu klassischen Schätzverfahren liegt zunächst in der Unterscheidung zwischen den Aspekten Umfang (Grösse und Komplexität) eines Vorhabens und die des Aufwandes. Geschätzt wird in abstrakten Schätzmethoden nicht der Aufwand in Zeitdimensionen wie Stunden, Tage, Wochen oder Monate, sondern vorab nur der Umfang des zu schätzenden Objektes in Form einer definierten Grösseneinheit (Points) bzw. seine Komplexität (Grad der Abhängigkeiten der Detailaspekte untereinander).

Der Wegbereiter dieser Methodik war Barry W. Boehm, der in der Software Entwicklung mit der Function-Point-Analyse den Fokus im Schätzverfahren von der Umsetzungsdauer hin zur Komplexität einer Software Funktionalität (Feature) verschoben hat. Der Umfang eines fachlichen Features lässt sich in einem abstrakten Komplexitätsmaß (den Function Points) ausdrücken. Der Aufwand, der zur Umsetzung des Features benötigt wird, leitet sich dann aus noch weiteren Faktoren (zB Anzahl von Feldern einer Datenbank) ab. 

Vorteile abstrakter Schätzmethoden

Vergleichende/abstrakte Schätzungen sind schneller durchführbar als das Schätzen absoluter Größen. Menschen können schlecht absolute Dinge schätzen. Sie können aber gut Dinge zueinander in Relation setzen und erkennen, was größer oder kleiner ist.

Umfangsschätzungen sind zeitlos - werden konkrete Zeitmaße verwendet, dann müssen häufig diese Schätzungen im Laufe eines Projektes durch Neuschätzung korrigiert werden. Beispielsweise dauert das Erstellen einer Formular-Eingabe zu Beginn eines Projektes durch fehlende Erfahrung vielleicht deutlich länger als im späteren Projektverlauf. Der Umfang (Grösse und Komplexität) hingegen bleibt aus Sicht des Teammitgliedes die gleiche und muss deshalb im Projektverlauf nicht angepasst werden.

Objektivität - durch die Trennung von Umfang und Aufwand können Schätzungen abgegeben werden, ohne die umsetzenden Individuen zu kennen. Bei der Schätzung des Umfanges einer Aufgabe muss nicht bereits die Geschwindigkeit unterschiedlicher Entwickler einkalkuliert werden, was die Schätzung aufwändig und personenbezogen machen würde.

Agile Schätzmethode in Scrum 

Die theoretische Annahme in der Methode Scrum ist, dass Produktfertigungs- und Entwicklungsprozesse in Softwareprojekten so komplex sind, dass sich die Umsetzung nicht im Voraus planen lässt, geschweige denn, die einzelnen Umsetungsschritte planbar sind. Somit ist es produktiver, wenn ein Team nur die groben Projektvorgaben in Form von User Stories bekommt. Planen wird in den agilen Methoden des Projektmanagements grundsätzlich als wichtiger Kommunikationsprozess zwischen Menschen verstanden, die ein gemeinsames Ziel verfolgen. 

Im Kontext agiler Projekte hat sich das Schätzen in abstrakten Schätzmaßen durchgesetzt. Hier wird nicht ein großes Lastenheft "am Stück" vor Projektstart geschätzt. Stattdessen werden die Anforderungen in Stories zerlegt. Jede Story beschreibt eine Anforderung, die für das Produkt einen Mehrwert darstellt. Die Stories sind so zu formulieren, dass sie innerhalb eines Zeitrahmens von ein bis zwei Wochen umsetzbar sind.

Die Vorteile im Detail

Der Vorteil dieser Zerlegung besteht darin, dass Stories sich in ihrem Umfang schnell schätzen lassen. Als Einheit werden Story-Points verwendet, die durch das Vergleichen verschiedener Stories vergeben werden (Analogieverfahren). Die Anzahl der Story Points drückt ausschliesslich ihre Grösse im Vergleich zu anderen User Stories aus. Eine User Story zB mit zwei Punkten ist doppelt so gross, wie eine User Story mit  einem Punkt. Die Anzahl der Story Points sagt jedoch nichts darüber aus, wie lange die Umsetzung der Story dauert. Dennoch sagt die Grösse in Story Ppoints etwas über die relative Dauer aus. Die Umsetzung einer User Story mit zwei Story Points dauert doppelt so lange wie die Umsetzung der User Story mit einem Point. 

Kriterien für den Umfang und damit die Grösse einer User Story können Faktoren sein, wie: Anzahl von Einzeltätigkeiten, generell das Arbeitsvolumen, die Komplexität, Risiken, externe Abhängigkeiten. Die Kriterien sind nicht fest und unterscheiden sich von Team zu Team.

Von der abstrakten Schätzung zur Aufwandsermittlung

Zur Aufwandsschätzung gelangt man durch den sogenannten Velocity-Faktor. Der Faktor gibt an, wieviele Story-Points in einem definierten Zeitbereich umgesetzt werden können. Im wesentlichen gibt es drei Möglichkeiten zur Ermittlung des Velocity-Faktors:

Historische Daten - aus der Vergangenheit ist bekannt, wie viele Story-Points das Team pro Zeiteinheit schafft. Dabei ist es wichtig, dass die Teamzusammensetzung vergleichbar ist.

Vorprojekt - ein kleiner Ausschnitt des Gesamtprojektes wird in einem kurzen Vorprojekt umgesetzt und daraus die Velocity-Kennziffer ermittelt.

Schätzen - liegen keine historischen Daten vor und kann kein Vorprojekt durchgeführt werden, dann kann ein grober Velocity-Wert aus der Erfahrung geschätzt werden. Natürlich können dann alle abgeleiteten Aufwandsschätzungen nur sehr grobe Näherungen darstellen.

Durchführung des eigentlichen Schätzvorganges in der Methode Planning Poker

Planning Poker ist in Scrum-Projekten in der Regel die Schätzmethode der Wahl. Sie wurde 2002 von James Grenning erstmalig beschrieben, später durch Mike Cohn’s Buch Agile Estimating and Planning verfeinert und erst durch seine Publikation populär.  In agilen Projekten wird großer Wert auf das Commitment und die Selbststeuerung eines Teams gelegt. Deshalb ist es beim Schätzen besonders wichtig, dass das gesamte Team einbezogen wird und die Schätzwerte unterstützt. Eine im agilen Umfeld weit verbreitete Technik ist das Ermitteln der Story-Point-Werte über sogenanntes Schätzpoker Verfahren (Planning Poker Methode). Dabei besitzt jedes Teammitglied Karten mit aufgedruckten Zahlen. Zu Beginn des Schätzvorganges einigt sich das Team auf eine verwendete Referenz Story. Das ist die kleinste oder die grösste User Story im Rahmen der zu schätzenden Sammlung an Stories (Backlog). Ich persönlich habe bessere Erfahrungen damit gemacht, als Vorgabe die kleinste gemeinsame User Story als Schätzbasis zu verwenden.  Die gesamte Schätzungsklausur wird vom Scrummaster moderiert und im Beisein des Product Owners abgehalten, der auch für Verständnisfragen zur Verfügung steht. 

Als Masseinheit für die agile Schätzmethode empfiehlt sich, die Zahlen der "unechten Fibonacci Funktion" zu verwenden. Dabei verwende ich persönlich in meinen Projekten nur die Punktereihe von 0 bis ausschliesslich 13, bzw. ?. Die Zahlen, die auf den Schätzpokerkarten aufgedruckt sind, haben folgende Bedeutung:

 0 - Kein Aufwand notwendig.

 1 - Sehr kleiner Umfang.

 2 - Kleiner Umfang: doppelt so wie ein kleiner Umfang.

 3 - Mittlerer Umfang: so gross wie ein sehr kleiner und ein kleiner Umfang zusammen.

 5 - Grosser Umfang: so gross, wie ein kleiner und mittlerer Umfang zusammen.

 8 - Sehr grosser Umfang: so gross, wie ein mittlerer und grosser Umfang zusammen.

13 - Riesiger Umfang: so gross, wie ein grosser und sehr grosser Umfang zusammen.

 ? - Nicht abschätzbar.

Abb.: Planning Poker Card Set

Ablauf:

• Der Produkt Owner lädt vorm ersten Sprint zu einem Initialmeeting mit nachfolgender Schätzklausur ein. Dazu hat er im Vorfeld alle User Stories (zumindest eine notwendige Anzahl für die ersten 1-3 Sprints) beschrieben und priorisiert.
• Der Product Owner schlägt vor Meetingbeginn den zeitlichen Rahmen vor. Dieser sollte je nach Teamgrösse maximal 90 Minuten nicht überschreiten. Er fasst das große Bild (Produktziel  bzw. die Produkt Vision) des zu entwickelnden Produktes zusammen und stellt dann vor jeder Schätzung das jeweilige  Backlog Item (User Story) kurz vor. 
• Im Schätzverfahren legt nun jedes Teammitglied pro Story verdeckt (und damit von den anderen unbeeinflusst) eine Karte mit dem geschätzten Wert auf den Tisch. 
• Anschliessend werden alle Karten gleichzeitig aufgedeckt. Gibt es nach dem Aufdecken der Karten große Abweichungen in der Einschätzung, dann wird im Team über diese unterschiedlichen Bewertungen diskutiert.  Dabei wird der Scrum Master die beiden jeweiligen Extremausprägungen der Schätzung (kleinster und grösster Schätzwert) befragen und lässt diese beiden Teammitglieder argumentieren, warum sie zu dieser Bewertung gekommen sind. Jedes Teammitglied hat nun damit weitere Standpunkte und Meinungen zur aktuellen Story gehört. Die Karten werden nun wieder aufgenommen. Dieselbe User Story wird jetzt von allen Teilnehmern neuerlich geschätzt. Nach ein bis zwei weiteren Schätzrunden sollten die Werte dann konvergieren. Auf diese Weise gelangt das Team schnell zu einem tieferen Verständnis der umzusetzenden Stories und zu guten Schätzwerten.
• User Stories die aufgrund vom Umfang grösser als 13 Punkte bewertet werden oder von der Detaillierung der Funktionen her betrachtet zu ungenau beschrieben sind, werden vom Team mit einem "?" geschätzt. Dies bedeutet für den Produktverantwortlichen (Product Owner), dass er diese im Anschluss an die Schätzklausur in eine detailliertere User Story zu definieren hat oder diese User Story in mehrere kleiner herunterzubrechen (zu schneiden) wird müssen, die dann neuerlich geschätzt werden.

Voraussetzungen:

• Derartige Schätzklausuren finden in agilen Projekten regelmässig während des Projektverlaufs statt, sodass zumindest immer zwei Projektphasen (Sprints) im Vorhinein die dafür benötigten User Stories geschätzt werden. Ich habe in meinen Projekten gute Erfahrungen gemacht, zu Beginn des Projektes in einer initialen Schätzklausur den kompletten Backlog und regelmässig nur die neu hinzugekommen User Stories zu schätzen. 

Anregungen:

• Teams ermüden nach etwa 2 Stunden Planungspoker.  Daher sind die bei grösseren Vorhaben die initialen Schätzklausuren auf mehrere kürzere Etappen aufzuteilen.

Vorteile:

• Agile Schätzmethoden mit der Methode "Planning-Poker-Verfahren" machen nicht nur mehr Spass als herkömmliche Schätzverfahren, sondern besitzen zudem folgende Vorteile:


• Teamentscheidungen
- Planungspoker ist ein kollaboratives Entscheidungsverfahren. Die Entscheidung sollte auf dem Konsens aller Teammitglieder aufbauen. So stellen sie sicher, dass das gesamte Team hinter den Schätzwerten steht.
• Schnelle Entscheidungen
- nach wenigen Schätzrunden einigen sich Teammitglieder meist rasch auf einen Schätzwert. Meist benötigt das Team dann ca. 2 Minuten oder sogar weniger, um eine User Story  abzuschätzen.
• Transparenz
- Produktverantwortliche, Team und Scrum Master nehmen am Planungspoker teil. Der Produktverantwortliche versteht so besser, wie die Aufwände entstanden sind. Ist das Team nicht in der Lage, einen Eintrag abzuschätzen, so wird dies vermerkt und bedeutet eine Überarbeitung der User Story durch den Produktverantwortlichen.

WEITERE AGILE SCHÄTZMETHODEN

Magic Estimation in der Methode nach Lowel Lindstorms

Diese „magische“ Schätzmethode macht eine zügige initiale Schätzung des gesamten Product Backlogs möglich, denn gerade beim Start eines neuen Projektes ist es häufig wichtig, schnell zu einer Aussage über den gesamten Umfang der zu entwickelnden Funktionalitäten zu bekommen. Wie schon von der Schätzmethode „Planning Poker“ her bekannt, sollten auch hier vor dem allerersten Sprint ausreichend Backlog Items für mindestens 1-3 Sprints im Backlog vorhanden und vom Product Owner priorisiert sein, um diese dann anschliessend vom Team schätzen zu lassen.

Mit dieser Technik lassen sich mit relativ geringem Zeitaufwand sehr aussagekräftige Schätzungen erstellen. Wie auch beim Planning Poker beschrieben, geht es bei der initialen Schätzung nicht um Präzision, sondern lediglich um eine erste Einschätzung.

Der Ablauf: 

Das Meeting läuft nach folgendem Schema ab:

• Der Product Owner druckt vor dem Meeting die einzelnen Backlog Items auf ein Blatt Papier (User Stories und Akzeptanzkriterien auf einer Seite) aus. Die Blätter werden auf dem Boden verteilt. 
• Er legt mit extra Karten (Planning Poker Karten) am Rand des Bodens eine Schätzskala mit der Reihung ähnlich nach Fibunacci (0, 1, 2, 3, 5, 8, 13, ?) auf.
• Der Product Owner schlägt dann im Meeting den zeitlichen Rahmen für das Meeting vor. Dieser sollte je nach Teamgrösse maximal 90 Minuten nicht überschreiten. Er fasst noch einmal das große Bild (Produktziel  bzw. die Produkt Vision) des zu entwickelnden Produktes zusammen und stellt dann alle Backlog Items einzeln vor.
• Alle Teammitglieder haben nun nacheinander innerhalb von maximal 10 Minuten die Möglichkeit, ihre Schätzung für alle Items auf dem Boden abzugeben. Die Schätzung kann durch das Auflegen von Poker Cards erfolgen oder der Einfachheit halber, mit dem Zuordnen der  User Stories dem entsprechenden Skalenwert auf der Schätzsskala am Bodenrand.
• Die Teammitglieder können bei Unklarheiten beim Product Owner nachfragen. Sie besprechen sich jedoch nicht untereinander, sondern nehmen nur die ausgetauschten Informationen auf.
• Der jeweilige Nachfolger kann die Schätzungen des Vorgängers entsprechend herauf- oder heruntersetzen. Stimmt er mit der Schätzung des Vorgängers überein, bleibt diese unberührt. Nachdem das letzte Teammitglied seine Schätzung abgegeben hat, wird diese Schätzung in das Backlog übernommen. 

Voraussetzung:

• Der wichtige Punkt vor dem Start des Projekts ist die Kenntnis des Big Picture, der Vision und der Zielsetzung des zu entwickelnden Produktes. Unter diesen Bedingungen fällt es einem erfahrenen Team leichter, Schätzung abzugeben.
• Als Voraussetzung für diese Technik sind gut geschriebene (geschnittene) Backlog Items (User Stories) und ein prall gefülltes Product Backlog hilfreich. Dabei kann der Scrum Master dem Product Owner im Vorfeld unterstützend zur Seite stehen und vorab die Backlog Items besprechen. Ausserdem sollte das Team vor dem Meeting in das Backlog sehen können. Das spart wertvolle Zeit im eigentlichen Schätzmeeting. 

Anregung:

• Veränderungen der Schätzwerte im Rahmen der Schätzklausur einer User Story sind ein Indikator für unterschiedliche Meinungen, Erwartungen und der Abschätzung unterschiedlicher Kompexität zur selben Story. Daher mein Tipp: Bei einer Veränderung der Schätzung einer User Story im Schätzvorgang gegenüber dem vorherigen Teammitglied, sollte diese mit einem Markierungspunkt markiert werden. Der Umstand eines Markers und die Anzahl der Markierungspunkte beschreiben den Grad der Meinungsunterschiedlichkeit zu dieser Story im Team. Diese Stories sollte der Product Owner mit dem Team nochmals durchgehen.
• Eine Herabsetzung der Schätzzeit von 10 Minuten auf 3-5 Minuten vermindert zwar in keiner Weise die Schätzqualität, kann jedoch bei übergrossen Backlogs zeitlich sehr hilfreich sein.

Magic Estimation in der Methode nach Boris Gloger

Die Idee von Lowel Lindstroms modifizierte Boris Gloger in seiner Schätzmethode "Magic Estimation". Die von Herrn Gloger entwickelte Methode schafft Schätzgeschwindigkeiten von ca. 100 Stories mit einer Gruppe von ca. 10 Personen in etwa 30 Minuten. Die dabei erreichte Schätzgenauigkeit ist für die weitere Umsetzung ausreichend. Diese Schätzmethode wird besonders bei Angebotsschätzungen oder bei sehr grossen Backlogs erfolgreich angewendet.

Der Ablauf: 

Das Meeting läuft nach folgendem Schema ab:

• Der Product Owner druckt vor dem Meeting die einzelnen Backlog Items auf ein Blatt Papier (User Stories und Akzeptanzkriterien auf einer Seite) aus. 
• Er legt mit extra Karten (Planning Poker Karten) am Rand des Bodens eine Schätzskala mit der Reihung ähnlich nach Fibunacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?) auf.
• Er bespricht zu Beginn nochmals die Product Vision und verteilt nun die Backlog-Item Karten an das Team. Jedes Teammitglied bekommt ungefähr gleich viele Karten.
• Das Schätzen wird von jetzt an nur mehr schweigend durchgeführt. Man darf sich mit niemanden (auch nicht mit dem Product Owner) austauschen. Voraussetzung dafür sind natürlich gut formulierte User Stories, die im Bedarfsfall schon im Vorfeld kommuniziert wurden.
• Jedes Teammitglied liest nun seine Backlog Items durch und legt sie zu der Zahl, die seiner Meinung nach das Verständnis dieser Story repräsentiert. Dabei gilt, je grösser die Zahl, desto grösser der geschätzte Umfang, wobei die Zahlen 20, 40 und 100 Epics und keine User Stories mehr repräsentieren. Es gelten nur die Werte der Schätzskala, also keine Zwischenwerte.
• Wenn ein Teammitglied seine Karten verteilt hat, liest es die Karten, die von den anderen Teammitgliedern ausgelegt wurden und verändert die Position der Karte, wenn es der Meinung ist, dass diese Karte an eine andere Position gehört. Dieses Lesen und allfällige Verrücken führen alle Teammitglieder parallel und ohne dass sie sich gegenseitig beraten durch.
• Der Product Owner beobachtet das Team beim Durchführen der Schätzungen. Wenn er sieht, dass eine Karte in der Bewertungsskala "springt", markiert er diese Karte. An einer Karte die springt, also die ein- oder mehrmals von Mitgliedern in der Skala verändert werden, lässt sich leicht erkennen, dass eine Meinungsverschiedenheit vorliegt.
• Wenn ein Teammitglied nicht weiss, was eine Karte bedeutet, dann wird es auf den Skalenwert "?" gelegt. Der Skalenwert "?" dient in diesem Schätzverfahren nur den unbekannten, also nicht interpretierbaren Backlog Items.
• Die Schätzung ist beendet, wenn sich keine Karte mehr bewegt oder es aber nur mehr "springende" Karten gibt.
• Zum Abschluss schreibt das Team die ermittelten Zahlen auf die Backlog Item Karten.
• Der Product Owner erhält als Ergebnis alle Backlos Items nach dem Verständnis "bewertet und final geschätzt".

Voraussetzung:

• Hier gilt ebenso die Voraussetzung von gut geschriebenen (geschnittenen) Backlog Items (User Stories).
• Das Team sollte vor dem Meeting das Backlog einsehen und dem Product Owner Fragen stellen können.
• Die Karten müssen in dieser Schätzmethode gut lesbar (in Großbuchstaben)  geschrieben werden.

Team Estimation Game

Gerade technisch sehr starke Teams neigen dazu, beim Schätzen bereits Lösungsansätze zu diskutieren. Als Argument höre ich dabei oftmals: “Für eine gute Schätzung müssen wir doch wissen, wie wir die Story umsetzen wollen“. Wenn man nun diese Diskussionen als Scrum Master ausufern läst, dauert die initiale Schätzung des Product Backlog länger als geplant. Das Team Estimation Game nach Steve Bockman liefert dazu eine schöne Lösungsmöglichkeit für dieses Problem. 

Ablauf:

Die Regeln für das Spiel sind sehr einfach gehalten und lauten:

• Das Team ist komplett vertreten. Der Product Owner ist anwesend. Der Scrum Master moderiert das Meeting.
• Alle User Stories liegen auf einzelnen Story Cards aufgedruckt und verdeckt auf einem Stapel.
• Jemand aus dem Team nimmt sich die oberste Story, liest sie laut vor und hängt sie an die Wand. Es kann bei umfangreicheren Backlogs durchaus der Boden als Platz für die Schätzung verwendet werden.
• Der nächste aus dem Team nimmt die nächste Story, liest sie laut vor und hängt sie ebenfalls an die Wand. Er hat drei Möglichkeiten:
• Die Story ist (seiner Meinung nach) ähnlich komplex wie die Erste. Dann hängt er sie neben die bereits an der Wand hängende Story.
• Die Story ist (seiner Meinung nach) weniger komplex als die bereits hängende, die neue Story wird über die bereits an der Wand hängende gehängt. 
• Die Story ist (seiner Meinung nach) komplexer als die bereits hängende, die neue Story wird unter die bereits an der Wand hängende gehängt.
• Ab der dritten Story Card gibt es die folgenden Optionen:
• Ausspielen der obersten Story Card wie oben beschrieben
• Umhängen einer bereits gespielten Karte, verbunden mit einer (kurzen) Erklärung, ohne Diskussion. Beim Umhängen der Story gegenüber dem vorherigen Teammitglied sollte diese mit einem Punkt farbig markiert werden.
• Aussetzen
• Das Spiel (Schätzklausur) ist beendet, wenn keine Story Cards mehr auf dem Tisch liegen bzw. alle Spieler aussetzen.

Man bekommt nun sehr schnell einen Überblick über die relative Komplexität des gesamten Backlogs, ohne dass man sich in Lösungsdiskussionen für einzelne Stories verlaufen hat. In der Regel wird man bei den Story Cards eine Cluster-Bildung beobachten, die sich nach dem Ende des Spiels hervorragend auf die Fibonacci-Reihe des Planning Poker Games projizieren lässt. Sollten es mehr als sieben Cluster sein (0, 1, 2, 3, 5, 8, 13, ?), kann man gemeinsam mit dem Team überlegen, ob und wie man Cluster zusammenfasst, z.B. indem man die beiden “kleinsten” Cluster zu einem macht. Dabei sollte man immer im Blick behalten, dass es sich hier um eine grobe Schätzung handelt und nicht um die Vorhersage der Zukunft.

Voraussetzung:

• Auch hier gilt als Voraussetzung, gut geschriebene (geschnittene) Backlog Items (User Stories) und ein prall gefülltes Product Backlog durch den Product Owner vorbereitet zu haben. Ausserdem sollte das Team vor dem Meeting in das Backlog sehen können. Das spart wertvolle Zeit im eigentlichen Schätzmeeting. 

Anregung:

• Je mehr farbige Punkte eine Story Card am Ende hat, desto weiter gehen offensichtlich die Meinungen bzgl. deren Komplexität auseinander. Dies ist auch ein gutes Indiz für den Product Owner, dass die Story möglicherweise noch nicht gründlich genug durchdacht wurde.

WEITERFÜHRENDE LITERATUR

Beck, K. et al. (2001): The Agile Maifesto, http://www.agilemanifesto.org, (Abfrage: 18.03.2009).

Bockmann, S. (2008): Team Estimation Game http://agileworks.blogspot.co.at/2008/01/team-estimation-game-by-steve-bockman.html. (Abfrage 14.04.2013).

Boehm, B.W.(1981): Software Engineering Economics, Boston.

Cohn, M. (2004): User Stories Applied. For Agile Software Development, Boston.

Derby, E./Larsen, D. (2006): Agile Retrospectives. Making Good Teams Great, Boston.

Grenning, J. (2002): Planning Poker. Renaissance Software Consulting. http://renaissancesoftware.net/papers/14-papers/44-planing-poker.html. (Abfrage 14.04.2013).

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Kaner et al. (1996): Facilitator´s Guide to participatory Decision Making. New York.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Schwaber, K./Beedle, M. (2001): Agile Software Development with Scrum, New York.

Schwaber, K. (2004): Agile Project Management with Scrum, Redmond.

Schwaber, K. (2007): The Enterprise and Scrum, Redmond.

Wirdemann, R. (2009): Scrum mit User Stories, München, Wien.

Scrum als Projektmanagement-Methode in der Software-Entwicklung von hochverfügbaren Softwaresystemen

Gespräch zwischen Bernd Speckbacher und Manfred Brandstätter zum Thema "Evaluierung von Scrum als Projektmanagement-Methode in der Software-Entwicklung von hochverfügbaren Softwaresystemen" 

Das Gespräch wurde als Interview von Bernd Speckbacher (BS) mit Manfred Brandstätter (MB), im Rahmen der Erstellung seiner Masterthesis an der  Donau Universität Krems - Department für E-Governance in Wirtschaft und Verwaltung, geführt. 

Die wichtigsten Passagen daraus werden nachfolgend beschrieben.

[BS]: Das Vertrauen vom Top Management wurde mir schon mehrere Male als Voraussetzung für den Einsatz der Methode Scrum genannt. Aber das findet man in der Literatur nicht so häufig, als es in der Praxis erwähnt wird, scheint jedoch die unternehmerische Praxis zu sein?

[MB]: Roman Pichler und Boris Gloger schreiben in ihren Werken, dass das Vertrauen des Managements vorhanden sein muss. Spätestens beim ersten Review, gemeinsam mit dem Kunden - hier bin ich als Manager genauso eingeladen wie die Kunden - wird das Vertrauen auf die Probe gestellt.

[BS]: Sie haben mit Ihrer Antwort schon eine meiner nächsten Fragen vorweggenommen, nämlich die Frage nach dem Haupttreiber für den Wechsel zu den agilen Methoden.

[MB]: Nachdem ich von meinen Kunden grundsätzlich nicht beauftragt werde, Scrum zu verwenden, sondern beauftragt werde Problemstellungen unter Zeitverknappung zu lösen, ist mein Zugang ein anderer. Meistens waren die Anforderungen: 

• Zu komplex geschriebene Spezifikationen, die in der traditionellen Methode niemals umsetzbar gewesen wären, 

• oder ein Projekt-Starttermin, der nicht 5 vor 12, sondern 10 nach 12 passiert ist, weil man - aus welchen Gründen auch immer - den Projekt kick-off verschlafen hat,

• oder Projektteams, die vorher noch nicht zusammengearbeitet haben, z. B. wegen regional unterschiedlicher Herangehensweisen, weil vielleicht ein Softwareunternehmen gekauft wurde, wie in dem vorher geschilderten Beispiel mit einem Entwicklungsprojekt an drei Standorten.

[BS]: Was steht es Ihrer Erfahrung nach mit der Qualität der Projekte, die mit Scrum umgesetzt wurden?

[MB]: Die Qualität ist genauso gut, oder genauso schlecht wie das verwendete Qualitätsmanagement, das in traditionellen Methoden der Software Entwicklung betrieben wird. Und das hängt davon ab, wie ernst ich den Qualitätsaspekt sehe. Das heißt, ich muss das Thema Qualität in Scrum, genauso in den Ablauf verankern, wie in der traditionellen Methode. Die "Definition of Done" (DoD) ist z. B. ein Aspekt, wo die Methode hilft, den Finger draufzuhalten, damit alle dieselbe Qualitätssprache zu sprechen. Aber letztendlich, ob ich ein white box oder ein black box Testsystem habe, oder ob ich nach 4-Augen-Prinzip teste, ob ich ein eigenes Test Team zur Verfügung habe, indem man sich gegenseitig ergänzt - anyway - ich muss den Qualitätsaspektt als strategische Vorgabe für mein Projekt fest schreiben. An erster Stelle steht die Qualität, und erst dann, wie ich zu dieser Qualität komme - unabhängig von der Methode.

[BS]: Gerade das V-Modell unterstützt dieses Streben nach Qualität ganz besonders, während Scrum einfach sehr viele Freiräume lässt. Wenn ein Team diese Qualitätsansprüche an sich nicht stellt, dann kommt im worst case nicht jene Qualität heraus, die ich benötige.

[MB]: Ja, so gesehen stimmt das natürlich. Beim Freiraum, den mir die Methode Scrum gibt - wenn ich auf die Qualität keinen Wert lege - da hilft mir Scrum nur bedingt weiter. Dasselbe gilt für das Risikomanagement: Es gibt kein explizites Ritual oder ein Artefakt in Scrum, das zB im Scrum Meeting besagt, ich sollte vielleicht eine vierte Frage stellen die auf die Qualität oder das Projektrisiko abzielt. Scrum ist in seiner Art und Weise genauso komplex wie die Regeln in der Software Entwicklung, nur nicht so kompliziert.

[BS] und versteht

[MB] … und versteht, dass dann sehr wohl das Qualitätsmanagement inkludiert ist. Das ist genauso, wie das Risikomanagement inkludiert, weil mir z. B. das Team frühzeitig sagt, was nicht funktionieren wird, sofern ich die Chance nütze, mit dem Team zu arbeiten und als Product Owner ernst nehme. Frühzeitig zu erfahren, worauf man bei den Qualitätstests achten muss - das sind die Anleihen, die in Scrum aus dem Lean Management (dem Toyota Produktionsmanagement) kommen. Ein kleine Metapher am Rande: Wenn ich einen amerikanischen Automobilmanager der alten Prägung frage, welche Qualitätskriterien er anwendet, dann sagt er: „Ausschussrate, Durchlaufzeit“ usw. Der Japaner wird nach kurzem Überlegen sagen: „Wir haben keine Qualitätskriterien in Form von Kennzahlen. Das einzige Qualitätskriterium für uns ist: Wir müssen einfach nur besser werden“.

[BS]: Also KVP [Kontinuierlicher Verbesserungs-Prozess].

[MB]: Genau das ist es: eine sehr simple Aussage mit einem sehr mächtigen Ergebnis. So sehe ich Scrum auch.

[BS]: Interessant. Das heißt, der Fokus des Teams auf die Qualität ist ein sehr wichtiger Einflussfaktor. Können Sie noch andere Einflussfaktoren auf die Qualität nennen, im Kontext des Projektmanagements?

[MB]: Zur Softwarequalität? … ja … Wir kennen in Scrum die User Stories, wir kennen andererseits die Constraints, also die Rahmenbedingungen. Und wenn ich in den Constraints jene Rahmenbedingungen reinschreibe, die die Qualität definieren, dann habe ich zumindest schon in meinem Product Backlog das Thema Qualität in Form funktionaler bzw. non-funktionaler User Stories verankert. Ich kenne Kollegen, die das Thema Qualität ganz einfach nur einem Qualitätsteam überantworten. Meine Herangehensweise ist es jedoch, zu den nichtfunktionalen User Stories zumindest 3 Qualitäts-Constraints, also Rahmenbedingungen verbindlich anzugeben, die die Qualität des Moduls ausmachen.

[BS]: Wir haben zuletzt über die Dokumentation gesprochen, ein anderer Einflussfaktor auf die Qualität ist die System- oder Software-Architektur. Auch hier sagt ja Scrum – überspitzt formuliert – „legen wir einfach los“. Das ist eigentlich das Gegenteil von Architektur, wo man erst einmal ein Rahmenwerk festlegt, erst einmal das große Ganze sieht und erst dann die Details mit Leben erfüllt.

[MB]: Scrum kennt sogenannte Explorations-Sprints, die eben das Ziel verfolgen, die Architektur zu entwickeln, um eine Arbeitsfähigkeit zu erzwingen, um eben allen auf denselben Informationsstand zu bringen, und/oder Softwarearchitektur auszuwählen; sozusagen unter Anderem auch nicht-funktionale Ergebnisse zu liefern.

[BS]: Die Frage war, wie sich die frühe oder späte Auswahl, oder das „gar nicht Verwenden“ einer bestimmten Software-Architektur auf die Qualität auswirkt.

[MB]: Eine saubere Definition im Rahmen des Explorationssprints erstellt, die Rahmenbedingungen sauber zu beschreiben - nämlich - was möchte ich eigentlich erzeugen, genauso wie man die Sammlung der Funktionalitäten in einem Sprint-Ergebnis beschreiben kann, das sind die Constraints, welche die Architektur beschreiben sollen. Ja, das ist das eine. Das andere sind die Personen, die das umsetzen. Das ist ein kritischer Erfolgsfaktor. Ein bestimmender Erfolgsfaktor ist ein zusammengespieltes Team, ein Team das mehr als nur mal ein Scrum Projekt gemacht hat. Ein erstklassiger, kein guter, sondern ein erstklassiger Product Owner, der die Gradwanderung zwischen dem funktionalen Verständnis, was der Kunde haben möchte, und dem notwendigen Tiefgang in der Softwareentwicklung hat, der ist für gute Ergebnisse wichtig. Und ein Scrum Master, der die notwendige Gelassenheit hat, um das Team arbeiten zu lassen, der nicht zu stark interveniert. Also, die Auswahl der richtigen Personen, darin liegt ein Erfolgsgeheimnis in der Verwendung von Scrum. Wenn ich eine Auswahl treffen müsste, würde ich den Product Owner als die wichtigere Rolle in Scrum Projekten definieren. Speziell in erfahrenen Scrum-Organisationen ist der Product Owner aus meiner Erfahrung die wichtigere Rolle.Der Product Owner hat die Verantwortung für das gesamte Produkt. Aberl in der Einführungsphase von Scrum in die Organisation, da hat aus meiner Sicht wiederum der Scrum Master die wichtiger Funktion inne.

[BS]: Wenn ich Sie richtig verstehe und Ihre Aussagen richtig interpretiere, dann ist also ein gut harmonierendes Team mit den richtigen Experten mit großem Abstand der bei weitem wichtigere Qualitätstreiber als alle Formalismen, Artefakte und alle sonstigen Vorgaben, die das Projektmanagement erfordert?

[MB]: Ja, exakt. Das ist es auf den Punkt gebracht.

[BS]: Aber es gibt ja auch andere Aufgabenstellungen in der Softwareindustrie, wenn es z. B. um sicherheitsrelevante Features geht. Ich weiß nicht, ob hier die Kreativität das Wichtigste ist.

[MB]: In den Unternehmen, die ich kenne, geht es oftmals um Prozessautomation. Hier können bei Softwarefehlern große Schäden auftreten. Dort hängt es auch von den Qualitätskriterien ab, nicht von der Methode. 

[BS]: Das heißt es gibt keine eindeutige Antwort, ob das Vorgehensmodell helfen würde, diese Fehler zu vermeiden, die Sie in der Vergangenheit gesehen haben?

[MB: Ja, das Modell Scrum gibt es nicht explizit vor.

[BS]: Vielen Dank für das Gespräch, es war sehr viel Information verpackt, die mir sehr weiter geholfen hat!

[MB]: Bitte gerne.

Agiles Change Management - iterative Herangehensweise bei komplexen Anforderungen

Grundsätzlich

Wandlungsprojekte in Organisationen sind hochkomplexe Projekte, verbunden mit einem Anteil an hoher Varietät. Die Schwierigkeiten liegen dabei oftmals in der Verwendung inkompatibler Methoden und Herangehensweisen sowie andererseits in der Lücke zwischen normativer Modellierung und realen Ausführung (vgl. Brandstätter/Gölzner/Siems, 2006, S. 25).

Derartige Projekte zeichnen sich oftmals mit einer hohen Misserfolgsrate aus. Die Begründung liegt neben überzogenen Erwartungshaltungen in der Zielsetzung, oftmals auch in mangelhaft durchgeführten Methoden für die Implementierung, sowie der notwendigen, jedoch nicht mehr durchgeführten laufenden Anpassung der Unternehmensorganisation. Diese nachfolgenden Adaptierungen werden großteils als aufwändig und mühsam empfunden und dadurch oftmals dem Tagesgeschäft untergeordnet.

Weitere Hindernisse wurden in einer Studie der TU-München (vgl. 2007) identifiziert.

• Unzureichendes Engagement der oberen Führungsebenen.
• Unklare Zielbilder und Visionen der Veränderungsprozesse.
• Fehlende Erfahrung der Führungskräfte im Umgang mit der Verunsicherung betroffener Mitarbeiter.
• Uneinigkeit auf den obersten Führungsebenen.
• Mangelnde Unterstützung aus dem Linienmanagement.
• Lückenhafte oder verspätete Information an die Mitarbeiter.
• Unzureichende Möglichkeiten zur Bewältigung von Ängsten und Widerständen der Mitarbeiter.
• Vernachlässigung psychologischer Faktoren in der Projektplanung.
• Ungenügende personelle Ressourcen.
• Wenig Vertrauen in der Kommunikation zwischen Mitarbeitern und Führungskräften.

Agiles Change Management 

Wenn der erfahrene Change Manager von Wandel im Kontext zur Unternehmensorganisation spricht, dann bedeutet dies für ihn zumeist das moderierte Gestalten der Ablauf- und Aufbauorganisation, sowie das Berühren eines sehr fragilen Beziehungsgeflechts zwischen den Personen in der Unternehmensorganisation. 

In der modellhaften Betrachtung, sind nun im agilen Change Management die Tätigkeiten in zwei definierten Phasen zusammengefasst:

1. Die Impulsphase - Hier werden, ausgehend von einem Wandlungsimpuls und der daraus resultierenden Aktivitäten, über die Definition einer Change Vision bis hin zu einer Organisationsgestaltung, die "revolutionären" Aspekte des Wandlungsprojektes behandelt. Dieses sogenannte Neuformen und kontinuierliche Ausprobieren sowie "Anfühlen" der „neuen“ Organisation  wird anhand einfacher Rituale umgesetzt und in iterativen Schritten, erreicht.

2. Die Viabilitätsphase (Betriebsphase) - Dies ist der Start des neuen „wandelnden Dauerszustandes“ einer Organisation. Diese ständige Adaptierung der Organisation ist daher der "evolutionäre" Teil des Wandlungsvorhabens.

Impulsphase

In der Impulsphase werden die betroffenen Unternehmenseinheiten (Abteilungen, Abläufe, Personengruppen) identifiziert. Daran folgt die fertige Identifikation der Aufgabenstellung, in Form einer gemeinsam zwischen Change Manager und Topmanagement formulierten Change Vision. Daran schliesst nahtlos der Vorgang für die Zusammenstellung, sowie Auswahl (eventuelle Selbstauswahl) des Teams an. 

Die Impulsphase beinhaltet nun folgende Tätigkeiten: 

• Bildung der Change Vision.
• Zusammenstallung und Auswahl des Teams.
• Konzeption eines Change Backlogs als Arbeitsgrundlage für die Entwicklung oder Überarbeitung der Teilprozesse, 
• das Simulieren und Testen der Teilprozesse, 
• das Abschließen und Abnehmen der Teilprozesse durch den Change Manager in der Projekt Review und 
• Übergang in die Viabilitätsphase.

Viabilitätsphase

Die Viabilitätsphase beschreibt die Aktivitäten vom Übergang der Impulsphase mit ihrer fertig simulierten Organisation in die des laufenden Regelbetriebes, mitsamt ihren ständigen Adaptierungen. Nach der Abnahmeprüfung der in der Impulsphase fertig simulierten und getesteten Organisation, geht diese in die "Phase" des Regulärbetriebes über. 

Jenes Team, das auch in der Impulsphase involviert war, übernimmt somit den Regelbetrieb und ist für die Einhaltung der selbst erstellten Anweisungen zuständig. Der Change Manager (zB HR-Management)  nimmt im Rahmen seines Tagesgeschäftes wieder den geregelten Arbeitsablauf in der Stammorganisation auf. Er ist jedoch weiterhin im Bedarfsfall, zB im Falle von identifizierten Organisationsänderungen, Ansprechpartner für das Team. Der Change Master wiederum, schließt nach erfolgreichem Projekt seine Tätigkeit ab, zieht sich in sein Team als Mitarbeiter zurück oder wird - sofern als externer Mitarbeiter in diesem Projekt rekrutiert - seine Tätigkeit in diesem Projekt beenden. 

Ziel der Methode des agilen Change Managements ist es, nach sehr kurzer Gestaltungszeit, einen schnellen Betriebszustand zu erzeugen um anschliessend den neuen Zustand auch langfristig erfolgreich „einfrieren“ zu können (Lewin, 1951; Kotter, 1996).

Verbesserungen von Prozessen oder Teilprozessen gehen grundsätzlich vom Team aus, werden vor ihrer Umsetzung jedoch vom Change Manager entschieden. Im Falle von anfallenden Adaptierungsmaßnahmen innerhalb des Prozesses, ist das verantwortliche Team für die Identifikation der Änderungen selbst zuständig. Es wird den Sachverhalt mit dem Change Manager besprechen. Dieser entscheidet dann, ob die Notwendigkeit eines neuen Projektes im Prozedere des oben beschriebenen agilen Change Managements (Impulsphase) gestartet werden sollte, oder ob dies auf „kurzem“ Weg in direkter Abstimmung z.B. mit der IT-Abteilung des Unternehmens abzuarbeiten ist. 

Änderungen im Rahmen des agilen Change Managements sind daher „anlassgetrieben“, erfordern keine regelmäßigen Meetings oder sonstigen Artefakte (zB Protokolle oder sonstige digitale Workflows). Die Erfordernisse für eine zeitnahe Adaptierung der Ablauf- und Aufbauorganisation im Änderungsfall sind:

• eine hohe Sensorik für Änderungen im jeweilig verantwortlichen Team und 
• die anschliessend notwendige Konsequenz, diese Änderungen auch umzusetzen.

Änderungen in der Unternehmenskultur sind im Rahmen von Change Projekten in der Methode des agilen Change Managements durchaus möglich. Der Autor hat bis dato jedoch nur Erfahrungen in Change Projekten in den Bereichen der Aufbau- und Ablauforganisation sammeln können. 

Weiterführende Literatur

Beer, S. (1973): Kybernetische Führungslehre, Frankfurt, New York.

Brandstätter, M./ Gölzner, H./Siems, F. (2006): Diversifizierte Kommunikation auf Basis des 

Event Life Cycle. Eine interdisziplinäre Betrachtung für die Stakeholder Netzwerkpartner, Mitarbeiter und Kunden. In: Proceedings of VI. Interdisziplinäres Symposium „Europäische Kulturen in der Wirtschaftskommunikation (EUKO 2006)”, S. 24-25, Turku.

Capra, F. (2002): Verborgene Zusammenhänge, Bern.

Doppler, K./Lauterburg, C. (2005): Change Management. Den Unternehmenswandel gestalten, 11. Aufl., Frankfurt a. Main.

Kostka, C./Mönch, A. (2001): Change Management. 7 Methoden für die Gestaltung von Veränderungsprozessen, München.

Kotter, J., P. (1996): Leading Change, Boston.

Laube, T./Schwandner, O. (2006): Technologie-Roadmapping-basierte Vorgehensweise zur Unterstützung des Technologietransfers in kmU. In Gausemeier, J. (Hrsg.): Vorschau und Technologieplanung. 2. Symposium für Vorschau und Technologieplanung Heinz Nixdorf 

Institut, 9. und 10. Nov. 2006, Schloss Neuhardenberg, Paderborn.

McK Wissen 08 (2008): Von der Amöbe lernen, http://www.brandeins-wissen.de/Downloads/McK/mck08_10.pdf, (Abfrage: 18.03.2008).

Morgan, G. (2002): Bilder der Organisation, 3. Aufl., Stuttgart.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Peters, T., J./Waterman, R., H. (2003): Auf der Suche nach Spitzenleistungen. Was man von den bestgeführten US-Unternehmen lernen kann, Heidelberg.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Preissing, W. (2008): Visual Thinking. Probleme lösen mit der Faktorenfeldmethode, München.

Pugh, D., S. (1981): The Aston Program of Research. Retrospect and Prospect, in Van de 

Ven A., H./Joyce, W., F. (Hrsg.), Perspectives on Organization Design and Behavior, New York, S. 135-166.

Reiß, M. (1997): Optimierung des Wandels, in Reiß, M. (Hrsg.): Handbuch für Change Management. Programme, Projekte und Prozesse, Stuttgart, S. 123-144.

Robbins, P. (2001): Organisation der Unternehmung, 9. Aufl., München.

Schneck O. (1994): Management-Techniken. Einführung in die Instrumente der Planung, 

Strategiebildung und Organisation, Frankfurt.

Scholl, W. (2004): Grundkonzepte der Organisation,  in H. Schuler (Hrsg.), Lehrbuch der Organisationspsychologie, 3. Aufl., Bern, S. 515-556.

Stolzenberg, K./Heberle, K. (2006): Change Management. Veränderungsprozesse erfolgreich gestalten - Mitarbeiter mobilisieren, Heidelberg.

Senge, P. (2003): Die fünfte Disziplin, 9. Aufl., Stuttgart.

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop running the race and start rugby. In: Harvard Business Review. Jan-Feb 1986, Harvard, S. 137-146.

TU-München: http://www.bertelsmann-stiftung.de/cps/rde/xbcr/SID-3034173B-82254146/bst/Studie_C4_2_2007.pdf

Von Rosenstiel, L./Dierkes, M./Steger, U. (1993): Unternehmenskultur in Theorie und Praxis: Konzepte Aus Ökonomie, Psychologie und Ethnologie, Frankfurt a. Main.

Von Rosenstiel, L. (2003): Grundlagen der Organisationspsychologie, Stuttgart.

Weick, K. (1995): Der Prozess des Organisierens, Frankfurt a. Main.

Die Optimierung des Markenbildungsprozesses mittels Scrum

Gemeinsam mit Fabio Aresu, dem Geschäftsführer der Branding Agentur Markenkern AG (www.markenkern.ch) in Chur in der Schweiz, habe ich vor wenigen Jahren ein interessantes Scrum-Projekt gestartet und möchte nachfolgend die Erfahrungen kurz zusammenfassen.

Abstract

Markenbildung ist schwierig und herausfordend. An dieser Tatsache ändert auch eine agile Organisationsmethode nichts. Denn das Wesen der Markenbildung ist Innovation und Kreativität. Jedes Projekt in dieser Richtung befriedigt nicht nur das Bedürfnis des Markeninhabers und -betreibers, sondern in erster Linie die des Bestands- und Neukunden dieser Marke. Oft scheitern Markenbildungsprojekte oder liefern Ergebnisse, die weder die Kunden zufriedenstellen noch die angestrebten wirtschaftlichen Ziele erreichen lassen (vgl. Esch, 2005, S. 24ff.).

Ausgangssituation und Problemstellung

Kein Markenbildungsprozess beginnt in der Praxis bei Null. Jedes neue Produkt und jede neue Dienstleistung ist in einen bestehenden Kontext eingebettet, um die Vermarktung schneller vorantreiben zu können. Dies bedeutet auch, dass die Projektmitarbeiter bewusst oder unbewusst nach einer für sie idealtypischen Herangehensweise zur Markenbildung vorgehen wollen. Somit prallen verschiedene Prozesse aufeinander, die in den meisten Fällen die Time-to-Market Phase erheblich verlängern, im schlimmsten Szenario sogar die Einführung gefährden, weil eine einheitliche Vorgehensweise und  zielgerichtete Kontinuität  in der  sensiblen Anfangsphase nicht gegeben sind.

Ablauf eines klassischen Markenbildungsprozesses 

Die nachfolgende Prozessbeschreibung in geraffter Form, soll die wesentlichen Elemente der Markenbildung kurz umreissen.

Auf Basis einer gründlichen Marktanalyse inklusive Desk- und Field Research wird der gewünschte Positionierungsraum der Marke definiert. Mit Hilfe einer klar definierten Vision, eines stringent umrissenen Brand Plans und der Formulierung des Markenversprechens wird die Strategie geformt. Darauf aufbauend erfolgen die operativen Massnahmen zur erfolgreichen Implementierung der Marke. Im Falle einer Neupositionierung muss darauf geachtet werden, die bisherigen zentralen Charakterelemente und –eigenschaften der Marke behutsam in einen neuen Positionierungsraum zu überführen. 

Probleme im Markenbildungsprozess 

Allgemeine Problemstellung

Auf Grund der komplexen Herausforderungen, namentlich in Kombination betriebswirtschaftlicher und wirtschaftspsychologischer Fragestellungen, werden oft Projektteams mit internen und externen Spezialisten gebildet. Dies bedeutet in der Praxis in der Regel, dass unterschiedlichste Vorgehensweisen, Analysemethoden und Problemlösungsszenarien aufeinanderprallen, die inkohärent sind und dem eigentlichen Ziel, eine starke Marke mit einer klaren Idee aufzubauen, diametral entgegenlaufen.

Probleme in traditionellen Markenbildungsprojekten

Das zentrale Problem traditioneller Vorgehensweisen besteht darin dass Marketingexperten  frühzeitig versuchen, alle Eventualitäten und Arbeitsdetails des Markenbildungsprozesses zu antizipieren und einzuplanen um anschliessend streng formalisert, dieses Programm als Projekt auszuführen (vgl. Pichler, 2008, S. 4). Gleichzeitig erhalten wir erst spät im Projekt Rückmeldung duch den Kunden über den tatsächlichen Projektfortschritt meist erst dann, wenn das Projekt schon im letzten Drittel der Markenbildung angelangt ist.

Lösung mit Scrum, einem Rahmenwerk für agile Projektorganisationen

Timeboxing als Orientierungsrahmen 

In Scrum - einer agilen Methode für Projektorganisationen - werden alle Aktivitäten der Markenbildung innerhalb einer fixen Zeitbox (fixer Zeitraum von 20 oder 30 Tagen) ausgeführt  - in Scrum wird dies als „Sprint“ bezeichnet. So bekommt das Projektteam nach wenigen Tagen Rückmeldung über den Fortschritt und wertvolle Informationen etwaiger Probleme und Hindernisse. Die Projektplanung fußt auf dem tatsächlichen Fortschritt des Projektes. 

Durch die Verwenden von kurzen Arbeitszyklen, an deren Ende IMMER ein Mehrwert für das Projekt (Fokusgruppenbefragung, Prototyp einer neuen Verpackung, Produktvergleichstests, uvam.) entstanden sein muss, werden Probleme frühzeitig offensichtlich. So besteht die Möglichkeit, rechtzeitig Ursachen von Problemen zu aufzufinden, Lösungsoptionen zu entwickeln und die richtigen Massnahmen zu ergreifen. Das frühe Auffinden von Problemen eröffnet dem Projektteam einen grösseren Handlungsspielraum und Flexibilität. Ergänzt wird die Theorie von Scrum durch die Art und Intensität in der Kommunikation in Abhängigkeit von der entsprechenden Projejktphase (vgl. Brandstätter/Gölzner/Siems, 2006).

Besonderheiten in der agilen Projektabwicklung 

Der Unterschied einer agilen Projektmanagementmethode - in diesem Falle Scrum  gegenüber der Projektorganisation in der klassischen Methode liegt in folgenden Aspekten begründet (vgl. Oesterreich/Weiss, 2008): 

• Scrum besitzt die Besonderheit, dass das Projektteam eigenverantwortlich in der Umsetzung agiert und innerhalb von fixen Zeitabschnitten fertige Detailergebnisse - so genannte inkrementale Produkte (vgl. Pichler, 2008, S. 32) - liefert. 
• Der Vorteil  der Methode Scrum liegt darin, dass das Erreichen eines fix definierten Endtermins einfacher zu erreichen ist, als in der klassischen Projektmanagementmethode. Die Begründung liegt in fixen Vorgaben für Zeit und Tätigkeiten.
• Scrum kommt grundsätzlich aus der Softwareentwicklung, ist aber nicht für Software Entwicklungsprojekte  alleine ausgelegt. Vielmehr versteht sich Scrum als generische agile Projekt Management Methode für unterschiedliche Projektarten (vgl. Pichler, 2008 S. 7ff.; Takeuchi/Nonaka, 1986, S. 237ff.). Diese Erkenntnis kann ich aufgrund meiner Erfahrung aus einer Vielzahl an abgeschlossenen Scrum Projekten ausserhalb der Software-Branche bestätigen.
• Scrum kennt gegenüber der traditionellen Projektorgansiation keine Rolle des Projektmanagers (vgl. Schröder, 1973, S. 27). Die Rollen in Srum lauten vielmehr:
• Product Owner - Verantwortlich für die Funktionalitäten und das Ergebnis des Markenbildungsprozesses, ist zumeist der Marketingleiter oder Produktmanager. Dieser gibt die inhaltlichen Anforderungen in einem priorisierten Product Backlog (Produktkatalog) , der in Form von „User-Stories“ verfasst ist.
• Scrum-Master – Verantwortlich für den Prozess, nicht für das Ergebnis ist zumeist ein erfahrener Mitarbeiter des Markeneigners oder derbeauftragten Agentur .
• Team – als interdisziplinäre Gruppe (bestehend aus internen und externen Mitarbeitern) führt alle Arbeiten, die zur Umsetzung der Anforderungen in auslieferbare Ergbnisse und Teilergebnisse (Produktinkremente) notwendig sind, eigenverantwortlich aus.
• Anwender – ist jene Pesonengruppe, die mit dem Projektergebnis arbeiten, konsumieren oder interagieren muss.

Vorteile in agilen Markenbildungsprojekten

Beim konsequenten Einsatz von Scrum werden folgende positive Aspekte spürbar:

• Kundenzufriedenheit: Durch die von Scrum bedingte enge Zusammenarbeit mit den Auftraggebern und Kunden (Markenkunden) und deren Einbeziehung beispielsweise in Anforderungsworkshops und Sprint-Reviews wird sichergestellt, dass das resultierende Markenergebnis zielgenau (Zeit- und Kostenplanung wird exakt eingehalten) erreicht wird.
• Time to market: Scrum ermöglicht durch eine strikte Priorisierung der Anforderungen, durch die Vermeidung von Fehlleistung und Ressourcen-Überlastung  das Projektziel des Markenbildungsprozesses zu erreichen oder zu übertreffen.
• Qualität: Scrum richtig angewendet führt zu einer spürbaren Verbesserung der Ergebnisqualität. 
• Produktivität: Durch enge Kollaboration, Selbstorgansiation, durch Bevollmächtiung der Projektmitarbeiter, durch das Vermeidem von Fehlleistungen und das Fokusieren auf die wichtigsten Anforderungen steigert Scrum die Produktivität.

Abb.: Artikel in der Zeitschrift Medinet Ausgabe 04/2008

Weiterführende Literatur

Brandstätter, M./ Gölzner/H., Siems, F. (2006): Diversifizierte Kommunikation auf Basis des Event Life Cycle. Eine interdisziplinäre Betrachtung für die Stakeholder Netzwerkpartner, Mitarbeiter und Kunden. In: Proceedings of VI. Interdisziplinäres Symposium „Europäische Kulturen in der Wirtschaftskommunikation (EUKO 2006)”, Turku, S. 24-25.

Deichsel, A., (2004): Markensoziologie, Frankfurt am Main

Esch, F-R. (Hrsg.), (2005). Moderne Markenführung, Wiesbaden

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Schröder, H., (1973): Eine Führungskonzeption für aussergewöhnliche Ereignisse, Wiesbaden.

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop running the race and start rugby. In: Harvard Business Review. Jan-Feb 1986, Harvard, S. 137-146.

Unger, F / Fuchs W., (2005), Management der Marketing-Kommunikation, Heidelberg