14 Fallbeispiel

In der IT-Beratung kommt es häufig vor, dass Kunden nicht mit der eigentlichen Problemstellung zum Berater kommen, sondern bereits mit Lösungsvorstellungen. Ob diese Lösungsvorstellungen sinnvoll sind und das Problem tatsächlich lösen kann von dem Berater erst ermittelt werden, wenn dieser das eigentliche Problem kennt. In diesem Kapitel wird anhand eines Fallbeispiels erläutert, wie als IT-Berater vorgegangen werden kann, um das Problem zu ermitteln und eine entsprechende Lösung mit dem Kunden zu erarbeiten.

Im Fallbeispiel geht es um ein Unternehmen aus der Finanz-Branche, in dem Scrum als Vorgehensmodell eingeführt werden soll. Zu Beginn werden einige Fragen genannt, die dem Kunden zu stellen sind. Durch diese erlangt man an wertvolle Zusatzinformationen.

Ziele:

• Was soll erreicht werden?

  Die Frage nach dem Ziel wird häufig mit indirekten Zielen beantwortet. Bezogen auf das Fallbeispiel: "Wir möchten UML als Standard in der Entwicklung einführen" statt "Wir müssen unsere Kommunikation verbessern."

• Welcher Nutzen soll erbracht werden?

  Antworten beziehen sich häufig auf Durchlaufzeiten oder ähnliches. Um im späteren Verlauf feststellen zu können, ob der Nutzen auch tatsächlich erbracht werden konnte, muss eine Ist-Zustandsaufnahme gemacht werden.

• Wer sind die Nutznießer?

  Die Frage nach den Personen, die von den Veränderungen profitieren sollen. Im Beispiel profitieren sowohl die Entwickler als auch das Management und die Kunden von der Einführung agiler Entwicklungsmethoden. Die Entwicklungszeiten werden durch verbesserte Kommunikation minimiert und damit die Kosten gesenkt.

Ergebnisse:

• Was soll genau herauskommen?

  Die Frage nach der Form durch die der Nutzen erbracht werden soll.

  "Beispiele sind regelmäßige interne monatliche Ergebnisreviews der aktuellen Software mit neuen oder angepassten Features durch die Qualitätssicherung, Produktmanager und andere Stakeholder." (S. 229)

• Was soll konkret hinterher da sein?

  Ein Beispiel technischer Natur wäre, das ausrollen von Releases innerhalb von Drei-Monats-Zyklen.

  Eine Antwort organisatorischer Natur könnte die Ausrichtung und Gruppierung der Entwicklung in Feature-Teams sein.

Vorhandenes:

• Was haben Sie bereits?

  Diese Frage deckt häufig direkt offene Punkte bei Kunden auf. Es entpuppen sich Unklarheiten.

• Woher haben Sie es?

  Falls es doch bereits Vorhandenes gibt, stellt sich die Frage nach dem Woher. Ist es in Eigenleistung entstanden? Wurde es ebenfalls durch ein Beratungsunternehmen eingeführt? Liegt die Kompetenz im Hause?

Benötigtes:

• Was brauchen Sie noch?

  Was ist noch notwendig um mit dem Projekt zu beginnen? Welche Eingangsartefakte sind noch nicht vorhanden?

Rahmen:

• Welche festen Randbedingungen sind einzuhalten?

  In welchem Budget-Rahmen bewegt sich die Beratung? Welche Mitarbeiter werden beim Veränderungsprozess fest eingebunden? Bleibt es bei der Zahl der Mitarbeiter bzw. sind weitere Einstellungen geplant?

• Welche Hindernisse sehen Sie?

  Die Hindernisse beziehen sich hierbei direkt auf die einzuführenden Veränderungen. Zum Beispiel, dass die abzustellenden Mitarbeiter eigentlich auch in anderen Projekten mitarbeiten müssen, oder das direkte Probleme in der Produktentwicklung Vorrang gegenüber dem Veränderungsmanagement haben.

• Welche Risiken befürchten Sie?

  Das Größte Risiko sieht die Geschäftsführung in dem Scheitern des Projektes als Ganzes. Das würde hohe Kosten und geringen bis gar keinen Nutzen bedeuten.

Aktivitäten:

• Welche groben Schritte wollen wir dazu gemeinsam gehen? An dieser Stelle werden erste Vorschläge durch die Beratung erbracht. Im Beispiel wird das durchführen erster Scrum-Workshops für die beteiligten Personen genannt. Außerdem wird das Vorbereiten der Produktmanager auf die zukünftige Rolle "Product Owner" und das Vorbereiten der Projektleiter auf die zukünftige Rolle "Scrum Master" genannt.

• Welche Abhängigkeiten gibt es?

  Im Beispiel wird nur eine Abhängigkeit genannt: Das durchführen aller Workshops vor der eigentlichen Einführung von Scrum. Eine gemeinsame Wissensbasis ist für den Erfolg des Projektes unabdingbar.

Grundlage des Beratungskonzepts

Das Beratungskonzept wird zweistufig aufgeführt. Es wird zwischen der Veränderungsebene und der operativen Ebene getrennt. In der Veränderungsebene werden die notwenigen Maßnahmen erarbeitet und getroffen, um das Unternehmen auf die Veränderungen auszurichten (Management-Ebene). In der operativen Ebene wird die inhaltliche Korrektheit der Durchführung sichergestellt.

Abbildung 1: Beratungskonzept (S. 235)

Die Gruppen bestehen aus folgenden Personen:

Transformationsteam: Auftraggeber und Führungskräfte

Projektmanagement-Governance-Team: Stellvertreter aus den verschiedenen Bereichen des Unternehmens.

Scrum-Rollout-Team: "Setzt den Veränderungsprozess als eigenständiges Projekt um." (S. 236). Das Initial-Scrum-Rollout-Team leistet hier Vorarbeit (z.B. erstes Backlog füllen).

Start-up-Team: "Bereitet das konkrete Projekt vor und führt die ersten Schritte durch. Dabei entwickelt es die Vision für das Projektergebnis und füllt das Product Backlog." (S. 236)

Scrum-Teams: Hier "erfolgt die Umsetzung des konkreten Entwicklungsprojekts, das aufgrund der Größe in unserem Beispiel als Scrum of Scrums und mit einem Product-Owner-Team realisiert wird."

Bei der Durchführung des Veränderungsprojektes haben die Teams aus der Veränderungsebene den gleichen Iterationszyklus, wie die Teams auf der operativen Ebene. Hierdurch können nach jedem Sprint die Ergebnisse aus den beiden Bereichen direkt aufeinander einwirken. In der operativen Ebene werden Produkte nach dem Vorgehensmodell Scrum entwickelt. Die Anpassung von Scrum an das Unternehmen und das definieren der notwendigen Prozesse findet in der Veränderungsebene statt. Nach jeder Iteration erhält die Veränderungsebene Feedback durch die operative Ebene. (Vgl. S. 237)

Das konkrete Umsetzungskonzept & Probleme lösen

Die Umsetzung erfolgt durch zwei Berater. Jeweils einer pro Ebene:

"Jeweils sowohl auf der Veränderungs- als auch auf der operativen Ebene hat einer der beiden Berater primär das Coaching der ScrumMaster und des Teams zur Aufgabe und der andere das Coaching der Product Owner" (S. 239)

Durch die Berater werden ebenfalls die initialen Workshops und Seminare durchgeführt. Eine Weitere Aufgabe ist es aus dem Scrum-Rollout-Team ein eigenes "agiles Competence Center" zu entwickeln. (Vgl. 239)

Veränderungen sind immer mit Problemen behaftet. Eine Aufgabe der Berater ist das Gespür für die Probleme zu entwickeln und diese Probleme entsprechend anzugehen. So wird als Beispiel genannt, dass eines der Scrum-Teams die Daily-Scrums für überflüssig hält. Die Aufgabe des Beraters ist es, das eigentliche Problem mit dem das Team zu kämpfen hat zu finden und die Grundsäulen des Vorgehensmodells (eine Grundsäule von Scrum sind die Daily-Scrums) zu verteidigen. Um das Team in die richtige Richtung zu lenken und das Daily-Scrum als Instrument nicht zu verlieren kann eine Anpassung des Daily-Scrums vorgenommen werden, sodass dieses nicht mehr als überflüssig aufgefasst wird. (Vgl. S. 241, 242)