REA.08: Die Produktorganisation

Der vorhergehende Blog „Produkte bestehen aus Business Capabilities“ hat sich mit dem Zusammen-hang Produkt – Team – Geschäftsfähigkeiten (Business Capabilities) beschäftigt. die plakative Aussage des Blog war «maximal zwei Teams sind für ein (Elementar-)Produkt verantwortlich» . Das löst jedoch nicht die Anforderung von vielen Unternehmen, wie ein höherwertiges Produkt oder Service identifi-ziert wird als Aggregation aus einer Anzahl an Elementarprodukten. Wenn wir also in einen grösseren Kontext gehen, in dem zehn, fünzig oder zweihundert Teams an einem Gesamtsystem arbeiten, welches aus vielen dieser (Elementar-)Produkt besteht, so sind Fragen zu kllären wie

• wer (Rolle, Team, Organisationseinheit) fühlt sich für ein (höherwertiges Produkt verantwort-lich
• welche Rollen sind dazu im Unternehmen sinnvoll oder relevant
• was sind good practices um Value Streams im Unternehmen zu identifizieren.

Die Produkt-orientierte Organisation

Tragen wir einige Erkenntnisse aus den früheren Blogs zusammen für die Aufstellung einer grösseren Organisation:

• Ein grösseres Unternehmen, welches ihren Kundinnen und Kunden mehrere ähnliche Produkte oder Services anbietet, ist wohl beraten die Systemlandschaft in den drei Schichten Infrastruktur, Plattform und kundenorientierte Angebote zu organisieren (siehe Blog 2).
• Die Produkte der Plattform nutzen die Schnittstellen der Produkte der Infrastruktur und die Produkte der kundenorientierten Schicht nutzen die Produkte der Plattform.
• Diese Richtung der Nutzung zwischen den Schichten ist strikt unidirektional. Die kundenorientierte Schicht nutzt die Plattform Schicht, die Plattform Schicht nutzt die Infrastruktur.
• Jede dieser Schichten besteht aus Elementarprodukten. Ein, maximal zwei Teams erstellen die digitalen Bausteine, welche die Fähigkeiten des Produktes implementieren und diese über digitale oder interaktive Schnittstellen den Nutzern zur Verfügung stellen (siehe Blog 7)
• Ein Team besitzt das fachliche UND technologische Wissen, um die Fähigkeiten seines Produktes unter Berücksichtigung der Strategie des Unternehmens zu entwickeln.
• Ein höherwertiges Produkt ist eine Aggregation der Elementarprodukte. Auch ein höherwertiges Produkt befolgt die Regeln eines Elementarproduktes, das heisst:
  • Definierte und versionierte Schnittstellen
  • Ein eigenständiger Lebenszyklus.
• Das bedeutet ein Unternehmen benötigt ein wohl strukturiertes Konfigurationsmanagement in der Enterprise Architecture als Voraussetzung.

Die Frage ist, wie ein Produkt-orientiertes Unternehmen eine Entwicklungsorganisation aufbaut. Wo ist die Profit-Loss Verantwortung abgesiedelt? Wie findet die Abstimmung statt, welche Fähigkeiten die Infrastruktur, die Plattform beziehungsweise die kundenorientierten Produkte besitzen? Wie findet Innovation statt?

Meiner Meinung nach geben hier skaliert agile Frameworks wie SAFe oder LeSS nur teilweise eine Antwort – zudem sie in vielen Unternehmen nicht im Sinne der Frameworks eingesetzt werden – was allerdings eher Gegenstand einer anderen Blogserie wäre.

Profit-Loss und inhaltliche Verantwortung

Interessant sind die Punkte

• Profit-Loss Verantwortung
• Verantwortung für höherwertige Produkte als Aggregation von Elementarprodukten

Starten wir mit der Verantwortung für höherwertige Produkte. Höherwertige Produkte entstehen als Aggregation von Elementarprodukten. Hier greift die Idee des Produkt Managers. Ich persönlich befürworte die letzte Entscheidungskompetenz auf dieser höherwertigen Ebene einer einzelnen Person in der Rolle des Produkt Managers zu geben statt einem Gremium. Ein Gremium, also ein Produktmanagement, kann Vorschläge entwickeln und durchaus auch Entscheidungen treffen. Im (leider häufigen) Fall von Entscheidungsschwäche ist es sinnvoll, wenn eine Person in der entsprechenden Rolle die Verantwortung besitzt zeitgerecht eine Entscheidung zu fällen. Ideal muss diese Person diese Verantwortung nie ausspielen. Alleine die Existenz einer einzigen Person in dieser Rolle födert in vielen Fällen das Verhalten des Gremiums Entscheidungen zu fällen.

Das Produktmanagement wiederum besteht ideal aus den Product Owner der Teams, welche die Elementarprodukte erstellen und einer Person, welche die Rolle des Produkt Managers für das höherwertige Produkt einnimmt. In vielen Unternehmen herrscht leider aufgrund einer europäisch geprägten konsensorientierten Kultur Entscheidungsunfähigkeit. Hier wäre ein wertvoller Ansatz zur Optimierung von Organisationen.

Jede der Schichten Infrastruktur, Plattform und Kunden-orientierte Produkte besteht (ideal) aus einigen (wenigen) höherwertigen Produkten. Der Produkt Manager besitzt die letzte Entscheidungskompetenz bezüglich der Fähigkeiten eines höherwertigen Produkts als Aggregation aus Elementarprodukten. Damit wäre ein Blueprint für eine Organisation definiert für die inhaltliche Entwicklung höherwertiger Produkte.

Kommen wir zur Profit Loss Verantwortung

Das mag nun für das Management seltsam klingen. Die Profit Loss Verantwortung liegt bei dem Produkt Manager, der ein verkaufbares Produkt auf den Markt bringt. Diese Rolle ist verantwortlich die geeigneten Leistungskennwerte des Produktes zu definieren und zu tracken wie Kundenzufriedenheit oder finanzielle Kennwerte. Diese Rolle orchestriert und koordiniert weitere Dienstleistungen aus dem Unternehmen wie Marketing, Sales oder Corporate Communication. Damit bestimmt diese Rolle jedoch nicht wie die Plattform aussieht oder welche Infrastruktur benutzt wird. Diese Rolle stellt Anforderungen an die Plattform.

Wie die Plattform aussieht oder welche Infrastruktur benutzt wird, ist das Ergebnis einer gemeinsamen Strategiediskussion mit den dort agierenden Produkt Managern. Ein Ergebnis dieser Strategiediskussion ist die Entwicklung der Fähigkeiten der Produkte jeder der drei Schichten (Kundenprodukt, Plattform, Infrastruktur) über die Zeit. Ideal wird das Ergebnis mittels eines kaskadierenden Zielfindungssystem, wie es zum Beispiel OKR darstellt, formuliert, welches für die Produkt Manager in jeder der drei Schichten Ziele formuliert.

Ein Ziel für Produkt Manager auf der Ebene Plattform könnte zum Beispiel die Lead Time sein, in welcher Fähigkeiten für die kundenorientierte Schicht zur Verfügung stehen, oder die Fähigkeit GDPR Anforderungen zu erfüllen. Ein Ziel für einen Produkt Manager der Infrastruktur Schicht könnte sein, wie gut Security oder Performance Eigenschaften erfüllt werden oder wie schnelle eine Testumge-bung in der Cloud zur Verfügung steht.

Mit diesem organisatorischen Aufbau sind Verantwortung und Entscheidungen in der Entwicklungs-organisation strukturiert und klar verteilt. Die strukturierte und klare Verteilung von Verantwortung und Entscheidungen ist entscheidend für die Resilienz, also für Fähigkeit des Unternehmens proaktiv mit Veränderungen umgehen zu können.

Value Streams identifizieren

Damit ist auch ein mögliches Muster definiert, wie Value Streams entstehen können unter Berück-sichtigung der Team Topologies. In der Schicht der Kunden-orientierten Produkte entstehen Value Streams rund um Stream-aligned Teams in einer Business Domain. Höherwertige Produkte in der Plattform können als Value Streams von Platform Teams gebildet werden. Höherwertige Produkte auf der Ebene der Infrsatructur, zum Beispiel der Cloud-Stack, können als Value Streams von Complicated Subsystem Teams gebildet werden.

Leider erkenne ich in vielen Unternehmen unklare Entscheidungsverfahren in Bezug auf die Weiter-entwicklung der Fähigkeiten von Produkten und Services. Es existiert ein Produkt Management in der IT, die Profit-Loss Verantwortung ist jedoch nicht bei diesem Produkt Management, sondern bei einer Business Organisation.

Solche Konstellationen mit Verteilung von Verantwortung und Entscheidungen fühen zu einer oft komplexen und langwierigen Entscheidungsfindung, da nicht klar ist, wo letztliche die Entscheidung für eine Produktfähigkeit liegt. Zumeist nimmt sich der Organisationsteil das Recht zur Entscheidung, welcher Profit-Loss Verantwortung besitzt. In dem Fall ist das Produkt Management in der IT in der Rolle eines Auftragnehmers. Das „IT Produkt Management“ ist typisch mit dieser Rolle unglücklich, da es die Gestaltungsfreiheit einschränkt. Das „Business“ mit Profit-Loss Verantwortung kann nämlich jederzeit in Eintscheidungen des Auftragnehmers hinein grätschen. Neben langwierigen Diskussion, Entscheidungsgerangel führt das zu unzufriedenen Mitarbeitenden auf beiden Seiten der künstlich geschaffenen Wand. Dieser Organisationsaufbau manifestiert die Trennung zwischen Business und IT, die wir eigentlich auflösen wollen – gerade um zu schnellen Entscheidungen zu kommen und die Anpassung der Unternehmens an Veränderung zu stärken.

Eigentlich ist alles bekannt…

Letztendlich sind die Ideen alle vorhanden, aus denen sich eine Organisation bedienen kann, um solche Dysfunktionalitäten zu verhindern. Die aus meiner Sicht relevanten Ideen und Konzepte liste ich hier auf, wobei diese Liste nicht abschliessend ist.

• Flight Levels von Klaus Leopold mit seinen kollaborativen Ansätzen, um von der Strategie bis zum Team zu kommen. Eine Alternative dazu wäre Denkplan.
• OKR als kaskadierendes und kollaboratives Zielfindungssystem
• Business Capabilities als Ansatz um Requirements Areas zu identifizieren
• LeSS als Ideengeber um Requirements Areas zu definieren
• Team Topologies, um die verschiedenen Ansprüche an eine Entwicklungsorganisation zu er-füllen
• Donald Reinersten mit seinem Buch über Produkt Development Flow, um Strategie, Fokus und Priorisierung zu adressieren
• Werkzeuge wie Kanban, um Dysfunktionalität im Flow zu Erkennen

Alle diese Konzepte und Prinzipien sind nicht gerade neu. Sie sind bewährt und zeigen Erfolge. Diese jedoch geeignet kombiniert anzuwenden ist herausfordernd. Es lohnt sich für Unternehmen hier zu investieren und die eigene Weiterentwicklung aktiv in die Hand zu nehmen. Und ja – wie in einem früheren Blog erwähnt: Ein komplexes Business Modell verlangt ein komplexes System zur Regelung.

… und jetzt doch noch ein Wort zu SAFe

An der Stelle erlaube ich mir ein persönliches Wort zu SAFe. SAFe hat alle diese Konzepte und Prinzipien eingebaut – und noch viel mehr. Da SAFe die Beraterwelt emotionalisiert, verzichte ich hier auf Lob oder Tadel. SAFe ist da und wird eingesetzt, Punkt. Die Herausforderung von SAFe für ein Unternehmen ist es aus dem Framework nur (!) diese Dinge herauszunehmen, die für das Unternehmen sinnvoll sind und dieses sinnvolle Set aus anderen Quellen zu ergänzen. SAFe ist ein Framework, kein Rezept. Bitte verwendet es doch auch so – Inspect & Adapt.

Die Fehler oder Schwierigkeiten, die ich persönlich in Unternehmen mit dem Einsatz von SAFe erkenne – und ich habe in den letzten 20 Jahren die Chance gehabt tiefe Einblicke in eine relevante Anzahl an Unternehmen zu erhalten und danke diesen Unternehmen dazu – sind:

1. Unternehmen nehmen alles von SAFe, weil SAFe (und die vielen SAFe zertifizierten Berater) das so lehren. Leider sind wirklich fähige Organisationsberater, die sich eine gewisse Unabhängigkeit von SAFe bewahrt haben und diesen Mindset vertreten, rar am Markt.
2. SAFe wird allein in der IT eingesetzt. Das Business weigert sich seine Machtposition aufzugeben und die echte Integration zu einer Produkt Organisation zu vollziehen. Es müsste schon ein erheblicher Change im Unternehmen stattfinden, um das zu ändern. Da jedoch zumeist Personen aus dem Business in die GL oder den Verwaltungsrat wachsen, gebe ich persönlich dieser Veränderung keine Chance. Ich hoffe ich überlebe diese Feststellung.
3. SAFe ist kompatibel mit der vorhergehenden Organisation. Im Prinzip ändert sich an der Verteilung von Verantwortung und an der Form Entscheidungen zu treffen fast nichts. Die identischen Personen wie zuvor treffen Entscheidungen (oder schieben diese im Kreis herum) wie zuvor. Die Verantwortung lastet nach wie vor auf den identischen Personen. Nur die Rollennamen und der Organisationsaufbau haben sich mit viel Aufwand geändert.

Zusammenfassend möchte ich sagen: Wir verfügen über alle Ideen und Informationen, um Organisa-tionen für die Welt und die schnellen Veränderungen in derselben fit zu machen. Ich als Berater habe selbst keinen neuen Ansatz. Meiner Meinung nach ist das meiste da, und den Rest ergänzt der Gesunde Menschenverstand. Eine good practice ist: Weglassen.

Wenn pfiffige Personen zuweilen unter neuen Namen neue Hypes mit bekannten Prinzipien auffrischen, so nehme ich persönlich solch einen Hype als Hook, um Unternehmen zu motivieren den nächsten Schritt zu gehen.

In meiner Beraterlaufbahn hat mir jedes Unternehmen bisher nachdrücklich bestätigt, dass es ganz besonders ist und sich von allen anderen Unternehmen unterscheidet – und dann führt es das Framework XYZ nach Rezept ein so wie alle Unternehmen.

I have a dream

Ich würde mir wünschen, dass Unternehmen spezifischer auf Ihre Bedürfnisse eingehen in der Nutzung eines Basis-Frameworks wie SAFe, LeSS oder Scaled Scrum oder wie immer es heissen mag und ihr eigenes Playbook@Unternehmen definieren als schlanker Subset, erhänzt mit weiteren Ideen auf dem Markt. Das mag SAFe@MyFirma heissen, wenn es sich primär daraus bedient oder FlightLevels@MyCompany.

Wesentlich ist, dass ein Unternehmens definiert, wie es die orthogonalen Aspekte Businesstreiber, Organisation und Technologie über die Anwendung der in dieser Blog Serie diskutierten Prinzipien adressiert – und diese Definitionen mit den Beteiligten erarbeitet und und schliesslich gelebt werden.

Danke.