Das Scrum-Training ist zu Ende. Alle Beteiligten sind zufrieden.
Viele neue Erkenntnisse. Aber wie setzt man sie um? Wie geht man mit den
bestehenden Strukturen um?
Im ersten Teil haben wir gesehen, dass Prozesseffizienz eine interessante Messgröße ist, um Prozesse besser zu verstehen. Wir sind immer noch bei der Frage, welche Rollen und Strukturen wir im Unternehmen brauchen.
Gute Scrum-Teams haben eine Lernkurve hinter sich und organisieren sich anders: Die GF verhandelt mit den einzelnen Bereichen, wie jeder Bereich zumUnternehmenserfolg beiträgt (Finanziell, Marktposition, Weiterentwicklung).
In jedem Bereich gibt es einen oder mehrere Product Owner, die für den wirtschaftlichen Erfolg verantwortlich sind. Sie sind erfahrene Unternehmer/innen im Unternehmen. Jeder PO hat ein oder mehrere Teams, die bei der Produktentwicklung helfen. Dabei decken die Teams den kompletten Technologiestack ab, damit es wenig Abhängigkeiten zu anderen Bereichen gibt.
Nun hat sich die Situation geändert. Feste Teams suchen sich Projekte. Projekte stören nicht mehr, sondern sind ein Baustein zu Finanzierung der eigenen Abteilung und zur Weiterentwicklung des Produktes. Entscheidungen können schneller getroffen werden. Der PO entscheidet, ob der Auftrag angenommen wird. Das Team entscheidet über die Umsetzung.
Damit können wir einige Wartezeiten aus dem Prozess nehmen. Statt 20 Tage Durchlaufzeit können wir nun schon nach 10 Tagen ausliefern.
Wie ändern wir die bestehenden Rollen? Was machen wir mit den Abteilungs-, Team- und Projektleitern? Wir könnten sie als erstes fragen: Wie willst Du zum Unternehmenserfolg bei dem gegebenen Rahmen beitragen? Welche Strukturen kannst Du fördern, um ohne Druck eine hohe Prozesseffizienz zu erreichen?
Wahrscheinlich werden einige Personen in die PO-Rolle gehen, andere übernehmen Scrum-Master-Aufgaben und wieder andere gehen als Experten in Teams.
Frank Verbruggen und andere haben übrigens einen guten Artikel zur Prozesseffizienz veröffentlicht./2/
Im ersten Teil haben wir gesehen, dass Prozesseffizienz eine interessante Messgröße ist, um Prozesse besser zu verstehen. Wir sind immer noch bei der Frage, welche Rollen und Strukturen wir im Unternehmen brauchen.
Woher kommt die Verschwendung in den Prozessen?
Tom und Mary Poppendieck haben Beispiele für Verschwendungsquellen in der Softwareentwicklung notiert./1, Chap. 1/- Halbfertige und angefangene Arbeit
- Unnötige Prozessschritte
- Überflüssige Funktionen
- Wechseln zwischen Aufgaben
- Wartezeiten, insbes. warten auf Entscheidungen
- Unnötige Bewegungen
- Fehler
- Wer gibt Arbeit in Auftrag und lässt sie nicht abschließen?
- Wer prüft regelmäßig, ob dies die im Moment beste Arbeitsweise ist, um einen Vorgang abzuschließen?
- Wer gibt Funktionen in Auftrag, die nicht oder sehr selten genutzt werden?
- Wer lässt Leute gleichzeitig an mehreren Vorgängen arbeiten?
- Wer darf welche Entscheidungen treffen und umsetzen?
- Welchen Abstand gibt es zwischen den Leuten, die das Wissen haben und die etwas umsetzen können?
- Wer lässt Prozesse zu, die immer wieder zu Fehlern führen?
Von Projekten zu Produkten
Das ist unsere Ausgangssituation: In der Hierarchie zwischen Geschäftsführung und Mitarbeitenden gibt es Personen mit disziplinarischer Verantwortung: Abteilungs- und Teamleiter. Zusätzlich gibt Rollen zum Umsetzen von Projektideen und zum Betreuen der täglich anfallenden Arbeit. Projekte suchen nach Mitarbeitenden und stehen in Konkurrenz zum sog. Tagesgeschäft. Projekte stören. Mit der Zeit haben sich komplizierte Rollen- und Machtspiele entwickelt, um Veränderungen und Routine irgendwie zu bedienen.Gute Scrum-Teams haben eine Lernkurve hinter sich und organisieren sich anders: Die GF verhandelt mit den einzelnen Bereichen, wie jeder Bereich zumUnternehmenserfolg beiträgt (Finanziell, Marktposition, Weiterentwicklung).
In jedem Bereich gibt es einen oder mehrere Product Owner, die für den wirtschaftlichen Erfolg verantwortlich sind. Sie sind erfahrene Unternehmer/innen im Unternehmen. Jeder PO hat ein oder mehrere Teams, die bei der Produktentwicklung helfen. Dabei decken die Teams den kompletten Technologiestack ab, damit es wenig Abhängigkeiten zu anderen Bereichen gibt.
Nun hat sich die Situation geändert. Feste Teams suchen sich Projekte. Projekte stören nicht mehr, sondern sind ein Baustein zu Finanzierung der eigenen Abteilung und zur Weiterentwicklung des Produktes. Entscheidungen können schneller getroffen werden. Der PO entscheidet, ob der Auftrag angenommen wird. Das Team entscheidet über die Umsetzung.
Damit können wir einige Wartezeiten aus dem Prozess nehmen. Statt 20 Tage Durchlaufzeit können wir nun schon nach 10 Tagen ausliefern.
 |
| Verbesserte Prozesseffizienz |
Wahrscheinlich werden einige Personen in die PO-Rolle gehen, andere übernehmen Scrum-Master-Aufgaben und wieder andere gehen als Experten in Teams.
Frank Verbruggen und andere haben übrigens einen guten Artikel zur Prozesseffizienz veröffentlicht./2/
Anmerkungen und Verweise
- /1/ Poppendieck, Mary ; Poppendieck, Tom: Lean Software Development : An Agile Toolkit. 1. Aufl.. Amsterdam: Addison-Wesley, 2003.
- /2/ F. Verbruggen, J. Sutherland, J. Martijn van der Werf, S. Brinkkemper, A. Sutherland: Process Efficiency – Adapting Flow to the Agile Improvement Effort, 52nd Hawaii International Conference on System Sciences, Wailea, Hawaii, 2019, abrufbar via https://www.scruminc.com/scrum-papers/
Kommentare
Kommentar veröffentlichen