Implementieren von Scrum in einer realen Matrix-organisierten Softwareabteilung

Ich arbeite als Leiter der Softwareabteilung in unserem kleinen Unternehmen (ca. 50 Mitarbeiter). Ich habe drei Entwicklungsteams mit jeweils 3-4 Mitgliedern. Eines der Mitglieder in jedem Team übernimmt die Rolle des Teamleiters. Eines der Teams arbeitet hauptsächlich an einem einzigen Projekt und es kommt selten vor, dass sie woanders aushelfen müssen. Die anderen beiden Teams arbeiten an 2-3 Projekten (für beide Teams gleich).

Mein Vorgänger hat kein Scrum oder ähnliches verwendet, im Grunde hat er die Arbeit nur sehr locker im Tages- bis Wochenrhythmus verteilt. Das führt natürlich dazu, dass keine Projektplanungs-/Steuerungsartefakte oder -prozesse vorhanden sind. Niemand wusste jemals, dass dies in der nächsten Zeit passieren könnte, und niemand konnte vorhersagen, wann eine Aufgabe abgeschlossen sein wird. Sie können sich vorstellen, wie die Projekte ablaufen.

Ich habe die Aufgabe, von hier aus weiterzumachen, und ich habe mich entschieden, mit der Implementierung von Scrum in den Teams zu beginnen. Natürlich bin ich mir in manchen Dingen immer noch sehr unsicher und brauche den Rat von Leuten, die einen ähnlichen Weg schon viel weiter gegangen sind.

Die Rollen:

• Wir haben kundenspezifische Projekte mit klassischen Projektmanagern und Projektingenieuren. Da sie sich bereits wie Product Owner verhalten, denke ich, dass es am besten wäre, das beizubehalten. Würdest du zustimmen?

• Wir haben auch einige interne F&E-ähnliche Projekte, um unsere Produkte oder Entwicklungstools selbst zu verbessern. Alle Arten von Menschen können solche Projekte vorschlagen oder anstoßen. Normalerweise leite ich sie von Anfang bis Ende. Ich würde für sie in der Rolle des Product Owners sein. Machst du das auch?

• Verwaltung der Zusammenarbeit und Kontrolle der verschiedenen Teams. Das ist eines der wichtigsten Dinge, für die mich das Unternehmen bezahlt. Ich denke darüber nach, so etwas wie Scrum of Scrums zwischen mir und den Teamleitern zu implementieren. Ich wäre hier in der Rolle des Scrum Masters, die mit der oben beschriebenen Product Owner-Rolle beißen kann oder auch nicht. Würdest du es mir empfehlen?

Die Verfahren und Artefakte:
Ich möchte langsam beginnen und sicherstellen, dass alle unserem Weg folgen.

• Die Dinge, mit denen ich beginnen möchte, sind die Pflege von Release- und Sprint-Backlogs, die Erfassung von User Stories, die Sprint-Planung mit der Aufteilung der Stories in Aufgaben und die Pflege von Task Boards sowie tägliche Stand-Ups.
  Wenn das funktioniert, würde ich weiterhin Schätzungen einführen, Diagramme abbrennen, die Entwicklungsgeschwindigkeit messen.
  Anschließend evtl. Messung individueller Optimismus-Faktoren der Entwickler zur Verbesserung der Projektabschlussprognosen.
  Würden Sie dieser Sequenz zustimmen oder etwas anderes tun?

• Was mir im Moment am meisten Kopfschmerzen bereitet, ist, wie man das alles macht, während man gleichzeitig an verschiedenen Projekten innerhalb einer Matrixorganisation arbeitet.
  Das Backlog: Sollte ich ein einziges haben, das alle Storys für alle Projekte erfasst? Das würde wahrscheinlich zu einer komplizierten Sprintplanung führen.
  Oder besser ein einziges Backlog für jedes Projekt? Aber wie würde ich dann Prioritäten zwischen verschiedenen Projekten erfassen? Zum Beispiel ist Geschichte a von Projekt 1 am wichtigsten, dann kommen Geschichte 1+2+3 von Projekt 2 und dann Geschichte 2 von Projekt 1 und so weiter.

• So schwer wie das oben Gesagte ist für mich die Vorstellung der Sprintplanungen. Teams sollten Storys aus dem Backlog ziehen. Aber wie sollten sie das tun, wenn mehrere Rückstände bestehen würden und die Prioritäten zwischen ihnen im Zickzack verlaufen?

Die letzten beiden Punkte verwirren mich am meisten, aber ich müsste sie lösen, bevor ich auch nur den ersten Schritt machen könnte.