Einführung von Scrum in die Unternehmensorganisation

Scrum ist ein Vorgehensmodell für Planung und Umsetzungssteuerung von Projekten, das vorwiegend in der Software-Entwicklung eingesetzt wird. Darüber hinaus begegnet mir Scrum aber immer mehr als Planungs- und Umsetzungswerkzeug in anderen Branchen, speziell überall dort, wo Forschung und Entwicklungsarbeit geleistet wird. In der Pharmaindustrie genauso, wie in der Automobilindustrie, Medienbranche und Nahrungsmittelindustrie hat Scrum neben den hauseignen IT- Abteilungen, in den F&E Labors Einzug gefunden.

Im Vordergrund von Scrum stehen Teamwork, regelmäßige und zyklische Lieferungen funktionierender Produkte bzw. Teilprodukte (Inkremente), enge Zusammenarbeit mit dem (internen bzw. externen) Kunden, arbeiten in fest definierten Zeitrahmen (engl. „timebox“) sowie die Fähigkeit schnell auf Änderungen (engl. „Change Requests“) zu reagieren.

Was bietet Scrum? 

Scrum setzt auf ein selbstorganisiertes (Software-) Entwicklerteam, das sich ohne einen Projektleiter organisiert und strukturiert. Damit das Entwicklerteam in Ruhe und ohne Störungen (Software-) Produkte entwickeln kann und darf, gibt es einen Scrum Master. Damit dieser Entwicklungsprozess (engl. Scrum Flow) eingehalten und auch kontinuierlich verbessert wird, tritt der Scrum Master zusätzlich als Bindeglied zwischen dem Entwicklungsteam und dem Product Owner auf und stellt dadurch die ergebnisorientierte „Lieferung“ von funktionierenden Produkten sicher. Durch seine schützende, ordnende und vermittelnde Rolle ist der Scrum Master einer der wichtigsten Change Agents in einem Unternehmen. Seine Rolle ist speziell in der Einführungsphase von Scrum in der Unternehmensorganisation von grosser Wichtigkeit.  Während er im Rahmen der laufenden Projektarbeit schwerpunktmässig als "Zeremonienmeister" für das Einhalten der Regeln und Rituale verantwortlich ist und als Abstimmungspartner zwischen Team und Product Owner fungiert, ist seine Tätigkeit in der Einführungsphase mehr die eines "Missionars" für die Methode. Dabei schafft er die notwendige Vertrauensbasis für die Methode Scrum beim Management und den Linienorganen des Unternehmens, berät den Product Owner in seiner neuen Rolle als  Autor von User Stories (im Gegensatz zu herkömmlichen Spezifikationsdokumenten) und steht dem gesamten Unternehmen als Ansprechpartner in allen Fragen der Methode Scrum zur Verfügung.

Meiner Meinung nach, bekleidet der Product Owner gegenüber dem Scrum Master in funktionierenden Organisationen die wichtigere Rolle. Das exakte "Schneiden" von Epics und User Stories sowie die schrittweise Gestaltung und ständige Kommunikation des Big Pictures eines entstehenden Produktes in iterativen Schritten, ist ein Erfolgsfaktor. In der Einführungsphase jedoch, liegt die Hauptverantwortung im Gelingen dieses Vorhabens in jedem Fall beim Scrum Master.

Wo liegen die Vorteile von Scrum?

Scrum besitzt seine unumstrittenen Stärken in hochkomplexen Projekten in Kombination mit meistens nicht eindeutig definierbaren oder volatilen Ergebnisszielen. Dies sowohl in kleinen Teams (5 - 9 Mitarbeitern) wie auch in mittleren und grossen Teams (bis zu 200 Mitarbeitern), auf einem oder mehreren Standorten verteilt. In Projekten mit eindeutig definierbaren und nicht ändernden Ergebniszielen ist zumeist die traditionelle Projektmanagementmethode nach PMI oder IPMA die idealere Methode.

Ist Scrum auch für Ihr Unternehmen geeignet? 

Scrum formuliert die Rechte und Pflichten des Entwicklerteams, des Product Owners sowie des Scrum Masters. Desweiteren basiert Scrum auf einen schlanken, flexibel anpassbaren und gut strukturierten (Software-) Entwicklungsprozess. Scrum ist eine sehr leistungsfähige Methodik um hoch effizient und hoch effektiv die Ergebnisziele eines Projektes zu erreichen. Jedoch erfordert der Einsatz von Scrum hohe Voraussetzungen in der Unternehmensorganisation: 

• Autonomie in der Umsetzung - das Team setzt eigenverantwortlich die Funktionen des Produktes um. Es ist in der Methode kein Projektleiter der klassischen Ausprägung vorgesehen, der Leistung, Termin und Kosten überwacht.
• Vertrauen des Managements in Richtung einer autonomen Umsetzung von Produkten durch ein Team ohne Vorhandensein einer Befehls- und Kontrollinstanz.
• Vertrauen des Teams in der Anwendbarkeit der Methode.
• Vertrauen des Product Owners in die Methode, speziell in der Autonomie der Methode.
• Offenheit - tägliche gelebte Offenheit in den Daily Scrum Meetings.

Agilitäts-Selbstcheck

Mit nachfolgendem Test fällt es leichter einzuschätzen, ob Ihre Organisation vom Einsatz agiler Methoden, wie zB von Scrum profitieren kann und ob die Voraussetzungen dafür gegeben sind. Dieser Agilitäts-Selbsttest entstand im Rahmen einer Forschungsarbeit zum Thema Projekterfolg in Zusammenarbeit mit der Fachhochschule Salzburg, im Studiengang Betriebswirtschaft und wurde von mir als Teilergebnis daraus konzipiert  (vgl. Brandstätter/Stumpf, 2012).

Der Selbsttest dauert in der Umsetzung ca. 15 Minuten und gibt Ihnen die Möglichkeit einer ersten Standortbestimmung zum Thema Agilität Ihres Unternehmens oder Unternehmensbereiches. Der Selbsttest ist in 3 Module (A bis C) unterteilt. In Modul A ermitteln Sie die Agilität im eigenen Unternehmen (Unternehmensbereich). In Modul B wird der Bedarf für den Einsatz von agilen Managementmethoden ermittelt. Dabei wird in B1 der Bedarf im Tagesgeschäft und in B2 der Bedarf im Projekteinsatz ausgewiesen. Abschließend geht es in Modul C um die Ermittlung der notwendigen Voraussetzungen Ihres Unternehmens (Unternehmensbereiches) in Hinblick auf den Einsatz von agilen Managementmethoden.

Geben Sie im nachfolgenden Selbsttest bei den aufgeführten Aussagen jeweils den Grad Ihrer Zustimmung an: 3 Punkte für Zustimmung, 2 Punkte für teilweise Zustimmung, einen Punkt bei Nicht-Zustimmung. Danach summieren Sie Ihre Punkte.

A - Die Agilität im eigenen Unternehmen bzw. Unternehmensbereich

1. Ein hoher Anteil an initiierten Aktivitäten bzw. Projekten wird erfolgreich abgeschlossen.

2. Unsere Aktivitäten bzw. Projekte unterliegen einer großen Wandlung.

3. Die Mitarbeiter inkl. Führungskräfte haben die notwendige Kompetenz zur Lösung von unerwarteten Anforderungen.

4. Die Mitarbeiter inkl. Führungskräfte haben den Entscheidungsspielraum zur selbsttätigen Lösung von unerwarteten Anforderungen.

5. Die Mitarbeiter inkl. Führungskräfte haben einen einfachen und schnellen Zugang zu allen formellen und informellen Informationen.

6. Unser tägliches Umfeld im Markt ist volatil und dadurch ständigen Schwankungen und Änderungen unterworfen.

7. Das Unternehmen besitzt mit sehr gut vernetzten Führungskräften und Mitarbeitern gute Sensoren in den jeweiligen Zielmärkten.

8. Die Mitarbeiter inkl. Führungskräfte kennen die eigenen "key earning drivers" des eigenen Unternehmens.

Ist die Summe höher als 16, ist die Agilität in Ihrem Unternehmen (Unternehmensbereich) stark ausgeprägt. Es reagiert rasch auf notwendige Änderungen. Änderungen erzeugen keine Irritationen in der Belegschaft. 

Liegt das Ergebnis höher als 8, befindet sich Ihr Unternehmen auf dem Weg in Richtung einer agilen Organisation.

Ergebnisse unter 8 deuten darauf hin, dass Ihr Unternehmen (Unternehmensbereich) starr organisiert und/oder stark formalisiert ist, sowie auf notwendige Änderungen langsam reagiert.

B1 - Bedarf an agilen Managementmethoden im Tagesgeschäft

9. Das Management Ihrer Unternehmensaktivitäten ist komplex und kompliziert.

10. Der Bedarf an schneller Reaktion auf Kundenanfragen im Kerngeschäft ist steigend.

11. Die Zufriedenheit der internen und externen Kunden Ihrer Produkte bzw. Services sinkt.

12. Die Anzahl der Änderungen in der Ablauf- und Aufbauorganisation steigen tendenziell an.

13. Die Anzahl von internen Projekten steigt tendenziell an.

Ist das Ergebnis höher als 10, ist der Bedarf für den Einsatz agiler Methoden im Tagesgeschäft ausgeprägt. In diesem Fall empfiehlt sich ein schneller Einstieg mit agilen Methoden und die Durchführung entsprechender Trainings.

Liegt das Ergebnis höher als 5, ist für den Einsatz agiler Methoden ein möglicher Bedarf gegeben.

Bei Ergebnissen unter 5, besteht mit hoher Wahrscheinlichkeit kein Bedarf für den Einsatz von agilen Managementmethoden im Tagesgeschäft Ihres Unternehmens (Unternehmensbereichs).

B2 - Bedarf an agilen Managementmethoden für Projektvorhaben

14. Die Erfolgsrate von Aktivitäten und Projekten ist rückläufig.

15. Die Komplexität der Projektvorhaben (Aktivitäten) steigt tendenziell.

16. Die Anzahl der Projektvorhaben (Aktivitäten) steigt tendenziell.

17. Unsere abgeschlossenen Aktivitäten und Projekte besitzen eine durchschnittliche Änderungrate von mehr als 30%.

18. Die durchschnittliche Anzahl an Mitarbeitern in meinen Vorhaben (Projekten und Aktivitäten) steigt tendenziell.

Ist das Ergebnis höher als 10, ist der Bedarf für den Einsatz agiler Methoden in Projekten ausgeprägt. In diesem Fall empfiehlt sich ein schneller Einstieg mit agilen Methoden und die Durchführung entsprechender Trainings.

Liegt das Ergebnis höher als 5, ist für den Einsatz agiler Methoden ein möglicher Bedarf gegeben.

Bei Ergebnissen unter 5, besteht mit hoher Wahrscheinlichkeit kein Bedarf für den Einsatz von agilen Managementmethoden in Projekten Ihres Unternehmens (Unternehmensbereichs).

C - Voraussetzungen für den Einsatz von agilen Managementmethoden für Tagesgeschäft bzw. Projektvorhaben

19. In der Organisation Ihres Verantwortungsbereichs existiert eine hohe Vertrauenskultur.

20. .... und es existiert eine ausgeprägt offene Fehlerkultur.

21. In der Organisation Ihres Verantwortungsbereichs besteht eine Verbindlichkeit zu autonomen Teams.

22. Das jeweilige Projektteam (Fachteam) wird nach den notwendigen Fähigkeiten und Begabungen individuell zusammengestellt.

23. In Ihrer Organisation existiert Knowhow bzw. Erfahrung im Einsatz von agilen Managementmethoden.

24. Ihre Mitarbeiter weisen eine hohe Projektverfügbarkeit auf.

Ist das Ergebnis höher als 12, sind die Voraussetzungen für den Einsatz von agilen Methoden in Ihrem Unternehmen ausgeprägt vorhanden.

Liegt das Ergebnis höher als 6, liegt eine bedingte Voraussetzung in Ihrem Unternehmen vor. Haben Sie darüber hinaus aber einen hohen Bedarf im Einsatz von agilen Methoden (siehe Pkt. B und/oder C), so sollten Sie dabei notwendige Bewusstseinsbildung und Ausbildung in der Organisation mittelfristig aufbauen.

Ein Ergebnis unter 6 bedeutet eine geringe bis keine Voraussetzungen für den Einsatz von agilen Methoden. Haben Sie darüber hinaus aber einen hohen Bedarf im Einsatz von agilen Methoden (siehe Pkt. B und/oder C), deutet dies darauf hin, dass Sie ehest möglich eine Verbesserung diesbez. mittels Bewusstseinsbildung und Ausbildung in der Organisation in Richtung Agilität herbeiführen sollten.

Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.

Weiterführende Literatur:

Brandstätter, M., Stumpf, M. (2012): Nachhaltigkeit im Projektmanagement – Bedeutung der Integrierten Kommunikation in der Innen- und Außendarstellung von Projekten. In: Umwelt-, Wirtschaftsforum, Heft 3-4/2012, S. 217-221. Springer-Verlag, Heidelberg.

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

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

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop Running The Race And Start Rugby. In: Harvard Business Review. Jan-Feb 1986, S. 137-146, Boston.

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

Witte, E. (1973): Organisation für Innovationsentscheidungen. Das Promotorenmodell. Schriften der Kommission für wirtschaftlichen und sozialen Wandel, Band 2, Göttingen.

Witte, E./Hauschildt, J./Grün, O. (1989): Innovative Entscheidungsprozesse: die Ergebnisse des Projektes "Columbus", Tübingen.

Wojda, F. (2000): Innovative Organisationsformen. Neue Entwicklungen in der Unternehmensorganisation, Stuttgart.

Womack, J., P./Jones, D., T. (1996): Lean Thinking, Auf dem Weg zum perfekten Unternehmen, 1. Aufl., München.

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.